MVCUSTODY
Digital asset custody software that runs beside your core banking platform.
Hold, move, service and prove tokenised assets on any chain, with the same discipline a bank applies to securities. Your bank stays the custodian of record. Your core stays your core. No single person, screen or vendor can move a client's asset alone.
Counts describe the design in the requirements document. They are not measured results.
The control and record-keeping layer behind a bank's digital asset service
MVCUSTODY is not a wallet and not an exchange. It answers the question a board, a regulator and a client will ask: can the bank hold, move and service any digital asset on any chain, prove that every client's asset is there, and show that no single person or system could have moved it alone?
HSM and multi-party computation key management, hot, warm and cold tiers, scripted key ceremonies, and an independent check of what is signed.
Policy as code, whitelists with cooling-off, limits, time locks, M-of-N approvals and a compliance gate through MVTRUST.
Double-entry ledger per client and asset, segregated or omnibus structures, and posting to the bank's general ledger.
Registry for tokenised real-world assets and NFTs, transfer restrictions, income and corporate actions, settlement against tokenised money.
Continuous reconciliation, proof of reserves, Regulator Replay, audit evidence, client statements, recovery and exit plans.
What MVCUSTODY does
Each feature states what it does and why it matters to a decision maker. Filter by layer.
Sign What You See
A deterministic decoder reads the raw transaction bytes and shows approvers a plain statement of what will happen. A second, independently written decoder in the signing zone refuses mismatched bytes.
HSM or MPC key management
Signing goes through the bank's chosen HSM or MPC partner. No signing path bypasses the signer gateway and no key is exported.
Hot, warm and cold tiers
Assets sit in tiers with different approval strength. Design target: hot tier under 2 per cent of assets.
Scripted key ceremonies
Witnessed, recorded ceremonies with evidence compiled for audit.
Policy as code
Limits, whitelists, time locks and approvals are versioned code under maker-checker control.
Policy Simulator
Replay up to 90 days of history against a new policy before it goes live.
Four-eyes on everything that matters
Anything that moves value, changes a setting or affects a person's record needs a second, different human approver. AI agents only draft.
Compliance gate through MVTRUST
Every incoming and outgoing movement is screened, with the decision stored on the transaction record.
Circuit Breaker
An automatic, tighten-only control can pause a hot wallet or raise approvals when danger is detected. It cannot loosen a control or release anything; a human does that.
One Vault, Every Chain
One account, policy set and ledger across chains. A new chain is an adapter, not a new platform.
Bank-ready books
Double-entry ledger of record with integer base units, posting fees and memorandum positions to the bank's general ledger.
Segregated or omnibus
Segregated by default, with omnibus as a recorded election per client.
Continuous reconciliation
Chain-to-ledger comparison, design target at most 5 minutes old for tier 1 chains. Breaks open with an investigation trail.
Asset Passport
Token, legal wrapper and registry link in one record, tested against the registry daily.
Transfer restrictions and servicing
Eligibility rules, income and corporate-action handling and client notices for tokenised bonds, funds and property tokens.
Delivery against payment
Settlement against tokenised money or wholesale CBDC through adapters. Planned for Phase 2.
Proof of Reserves on Demand
A signed, checkable statement of assets against liabilities. Design target: under 4 hours from request.
Regulator Replay
Replay any decision with the policy, approvals, screening result and decoded statement as they stood at the time.
Client transparency portal and approver app
Live positions, movements and statements for clients, read only. A mobile app for approvers with device-bound keys.
Exit plan always ready
Rehearsed plans to return client assets and to leave a chain or partner.
13 governed AI agents
Agents read chains, contracts, policies and records and draft decisions: intent explanation, break investigation, policy drafting, contract risk reading, corporate actions, reporting and more.
Security by design
Field-level AES-256-GCM encryption with per-tenant keys, TLS 1.2 or higher, forced row-level tenant isolation, idempotency keys on every write, signed webhooks, and a hash-chained audit ledger.
Feature switches under control
Every function sits behind its own switch, off by default. Changing a switch is a configuration change that needs a second approver.
English and Arabic, GCC-first
English and right-to-left Arabic from the first console screen. Data residency, retention and cut-off time are settings per bank. Arabic text is reviewed by a native speaker before use.
Degrade, never lie
Under failure the system states what it could not do. It never shows an action as done when it is not.
One transfer, from request to proof
Select a step to see what happens, who is involved and what the bank controls.
A client or operator raises a transfer
The request arrives in the web console or client portal. Client identity comes from MVKYC, and the account structure comes from the custody ledger.
- Every write carries an idempotency key, so a retry never sends twice.
- The request is a draft until the checks and approvals complete.
- The client's data is separated from other clients by row-level security.
Policy and compliance checks run first
The policy engine tests limits, whitelist cooling-off and time locks. MVTRUST screens the destination and applies travel-rule rules.
- Rules are versioned code that was simulated against history before release.
- The screening decision is stored with the transaction record.
- A failed check stops the transfer before anyone is asked to sign.
Named humans approve what the bytes do
The Intent Verifier decodes the transaction from raw bytes into a plain statement. Approvers read that, not the screen that built the request.
- M-of-N approvals, with a second, different human for each approver role.
- Approvers use the mobile app with a device-bound key.
- AI agents may explain and flag. They cannot approve.
The signing zone checks again, then signs
A second decoder in the isolated signing zone, written independently, compares the bytes with the approved statement. A mismatch is refused.
- Signing goes through the bank's HSM or MPC partner.
- Keys and quorum stay in the bank's control domains.
- Congestion handling re-prices within limits and never double-sends.
The core banking platform is updated
The core adapter posts fee income and memorandum positions to the bank's general ledger. Where the core accepts only batch files, the adapter posts at the cut-off and reconciles the totals.
- MVCORE is the default adapter. Other cores use the same interface.
- The client sees positions live in the portal. Finance receives them in the core's own form.
- No partial posting: a failed posting rolls back every entry.
The bank can prove it
Reconciliation compares the chain with the ledger. Proof of reserves, statements and Regulator Replay are available on request.
- Hash-chained audit entries with signed checkpoints.
- Evidence packs for auditors and supervisors.
- Rehearsed exit and recovery plans.
It does not replace the core. It sits beside it.
The core stays the bank's general ledger and the owner of client and account records. MVCUSTODY holds the digital asset records and controls, and passes the accounting results to the core through an adapter.
Integration
MVCORE is the default core adapter. Custody positions and fees post to the general ledger through it.
What the core keeps
General ledger, client and account records and cash accounts. Nothing moves out of the core.
What the bank gains
Digital asset custody under the same ledger, reporting and controls it already uses for securities.
Integration
The adapter reads client and account references and posts fee income and memorandum positions as they occur.
What the core keeps
It remains the system of record for the bank's own books. Custody positions appear as memorandum accounts.
What the bank gains
Same-day books without re-keying. A new core is a new adapter, not a change to MVCUSTODY.
Adapters for cores other than MVCORE follow the same interface. Each one is scoped and tested with the bank during the pilot.
Integration
The adapter builds a posting file at the bank's cut-off, reads the acknowledgement and reconciles the totals to the custody ledger.
What the core keeps
Its own file-import process and controls. No change to the core is needed.
What the bank gains
Clients see positions live in the portal while finance receives the same figures in the form the core expects.
Sign what you see
In February 2025, about USD 1.5 billion left a large exchange after attackers altered the signing interface its approvers relied on, as reported by BlockSec. The approvers followed procedure. The screen they trusted was wrong. MVCUSTODY adds a second reader that does not trust the screen.
What a request screen may claim
What the raw bytes actually do (illustrative)
Illustration of the design. Not a recorded event on a Moneyverse system.
Measured against what a bank should demand
"Best in class" is a standard to be proven, not a claim to be assumed. The table sets out what a bank's board and supervisor should expect from a custody platform, what is typical today, and how MVCUSTODY is designed to meet it.
| What a bank should demand | Typical situation | MVCUSTODY design |
|---|---|---|
| Approvers see the truth | Approval on a screen the bank cannot independently verify | Two independent decoders on raw bytes, mismatch refused |
| No single point of control | One vendor or one operator can move assets | HSM or MPC across trust domains, four-eyes, no Moneyverse key share |
| Chain coverage | One or two chains per vendor, a new chain is a new project | Adapter registry. EVM, layer 2, Besu, Bitcoin, Solana in the MVP |
| Books of record | Vendor ledger separate from the bank's general ledger | Double-entry ledger, posting to the core, continuous reconciliation |
| Tokenised real-world assets | Token held, legal link tracked in spreadsheets | Asset Passport with transfer restrictions and registry tests |
| Compliance | Separate screening and travel-rule process | MVTRUST gate on every movement, before signing |
| Client transparency | Periodic statements | Live positions, proof of reserves, statements on demand |
| AI under control | Models given broad access, or none | 13 agents that draft only. One tighten-only exception |
| Exit | Plan on paper | Rehearsed return and migration plans |
"Typical situation" is a general description from the requirements document, not a review of any named vendor. Comparisons with specific products need a separate, evidenced study.
Design-target scores
Scored 1 (poor) to 10 (best in class) by the document's author. They are judgements, not measurements, and are to be tested in the pilot.
What it changes, by role
A defensible way into digital assets
Launch a service without rebuilding the core. Control stays with the bank, and the evidence exists to answer a supervisor.
One dashboard for every chain
Assets under custody by chain and tier, breaks, pending approvals and servicing events in one place.
Controls you can show
Policy as code, four-eyes, screening before signing, tighten-only circuit breaker and replayable decisions.
Fewer manual reconciliations
Breaks are found within minutes of arising and come with a drafted investigation. A person approves any closing entry.
Custody that posts to the core
Fees and memorandum positions reach the general ledger. Evidence packs and hash-chained audit trails support the review.
See their own assets
Live positions, movements, statements and proof of reserves, read only, scoped to their own data.
Chain-neutral, with evidence-based admission
The books of record sit in the Moneyverse ledger and the bank's core. The chain only decides where a client's asset is held. A chain enters the registry as live only after it is scored on resilience record, depth of tokenised assets, token standards and tooling, signing-curve support, and client and regulator demand.
| Chain family | Position | Note |
|---|---|---|
| Ethereum and EVM networks, one layer 2 | MVP | Largest base of tokenised assets, standards and tooling |
| Hyperledger Besu | MVP | Same adapter serves permissioned bank networks |
| Bitcoin | MVP | UTXO adapter |
| Solana | MVP | Needs ed25519 support at the HSM or MPC partner |
| Stellar, XRP Ledger | On demand | When a client requires them |
| Canton, Fabric, CBDC platforms | On request | Institution-led permissioned networks |
| Move-based chains | Deferred | Only on a named client need and a passed resilience review |
MVP chains run on test networks or local nodes. Inclusion of a chain is not a recommendation to hold any asset and does not imply a commercial arrangement.
From test networks to production custody
Pilot on test networks
Policy set, signer adapter, five chain families, Intent Verifier, ledger and daily reconciliation, web console, approver app, basic Regulator Replay, Asset Passport for one asset class.
Production for the pilot bank
Selected chains, proof of reserves, tokenised bond servicing, delivery against payment, core posting, evidence pack.
Scale
Further chains, NFT and property-token servicing at scale, CBDC and permissioned-network adapters, exit and recovery rehearsals as a service.
First target region: the Gulf Cooperation Council states, with data residency, retention and cut-off time set per bank. Regulatory mapping is to be confirmed by counsel before any pilot.
Questions decision makers ask
No. A licensed bank or custodian operates MVCUSTODY and remains custodian of record, accountable for every asset and approval. Moneyverse holds no signing authority and no key share that could move client assets alone.
No. MVCUSTODY posts to the general ledger through an adapter. MVCORE is the default. Other cores use the same interface, in real time or in batch at the cut-off.
The bank, through its chosen HSM or MPC partner. MVCUSTODY enforces policy and quorum and never exports a key.
No. Agents read and draft. A named human approves. One narrow class may tighten a control, for example pausing a hot wallet, but can never loosen a control or release an asset.
No. MVCUSTODY is in design and build, with a pilot on test networks planned first. Production custody follows partner certification, counsel's opinion on the legal structure, insurance and the bank's licence arrangements.
Not yet. ISO 27001 and SOC 2 Type II are targets under preparation, not claims. Security claims need independent assurance, including penetration testing, before any bank relies on them.
The GCC first, with English and Arabic from the first screen. Residency, retention and cut-off time are per-bank settings. Regulatory mapping is to be confirmed by counsel before pilot.
No. Moneyverse is a software provider. A token's legal effect depends on the law of each jurisdiction and is a matter for the bank's counsel.
Plan a custody pilot with your bank
Request a briefing. We will walk your securities services, risk and technology teams through the design, the core adapter and what a pilot on test networks would involve.