Multi-Regulator Custody: One Wallet Architecture Across VARA, MiCA, MAS and FCA Rulebooks

Four regulators, four rulebooks, one set of private keys. The temptation is to fork the custody platform per licence. The temptation is wrong, and it is expensive in a way that compounds.

A custodian holding client virtual assets under a VARA licence in Dubai, a MiCA authorisation in the EU, a Major Payment Institution licence in Singapore and a UK cryptoasset registration is not running four businesses. It is running one wallet estate that four supervisors will inspect against four differently-worded rulebooks. VARA, MiCA, the Monetary Authority of Singapore and the FCA each demand segregation of client assets, controls over cold storage, and disciplined management of private keys. They just word those demands differently, and in places they set different numeric floors. The engineering question is not whose rule wins. It is how to build one platform that satisfies all of them at once, without maintaining parallel builds that drift apart the moment one regulator moves.

Where the four rulebooks actually diverge

Start with segregation, because it is the requirement every regime shares and words most differently. MiCA’s Article 75 requires custodians to hold clients’ crypto-assets segregated from their own, both legally and operationally, on the distributed ledger and in the firm’s internal systems, and to keep a register of positions for each client that records every movement as soon as possible. MAS requires DPT service providers to hold customers’ assets on trust and segregate them from the firm’s own assets, with daily reconciliation and movements controlled by senior managers resident in Singapore. The FCA’s proposed custody regime, consulted on in CP25/14 in May 2025 with final rules expected during 2026, frames the same idea as a non-statutory trust with client assets kept distinct from the firm’s, individually segregated or in omnibus wallets, reconciled daily. VARA’s Custody Services Rulebook sets its own segregation-and-control and wallet-management standards. Same intent, four vocabularies.

Then look at cold storage, where the numbers stop agreeing. MAS is explicit: at least 90% of customers’ tokens must sit in cold wallets, leaving no more than 10% in hot or other wallets. MiCA and the FCA regime do not fix a single headline percentage; they demand that keys and access be kept secure and that the custody policy justify the storage split against the risks. VARA sets wallet-management requirements without pinning the whole industry to one universal ratio. If you build to MiCA’s qualitative standard, you fail Singapore’s numeric one. If you build to Singapore’s number everywhere, you are already compliant on that axis in every other jurisdiction. That asymmetry is the whole design principle.

Key control tells the same story. Every regime expects that no single person can unilaterally move client assets and that key generation, storage and use follow a documented ceremony. The specifics — quorum size, who may hold a share, where they must reside — differ. Singapore’s residency constraint on the people who authorise movements has no direct equivalent in the others, so it becomes an additional constraint the shared platform simply has to carry.

The strictest common denominator, encoded as configuration

The design move is to stop treating each rulebook as a separate implementation and start treating it as a separate profile over one implementation. Each jurisdiction gets a declarative policy profile: cold-storage floor, segregation model, reconciliation cadence, signing quorum, residency constraints on key holders. A resolver reads all the active profiles and computes a single effective configuration by taking the strictest value on each axis. The platform then runs against that effective configuration, not against any one regime. You do not fork the codebase; you fork the data.

“Strictest” has to be defined per field, because it is not always “largest number”. For a cold-storage floor, strictest is the maximum. For reconciliation frequency, strictest is the shortest interval. For segregation model, individually-segregated is stricter than omnibus. For residency, strictest is the union of every constraint, because a rule that binds in one place does not stop binding because another place is silent. Get those comparators right and the resolver is small, testable and auditable.

# custody-policy.yaml
# Per-jurisdiction profiles, resolved to a strictest-wins effective config.
# Verify each value against the current rulebook before relying on it.

defaults: &defaults
  segregation_model: omnibus        # omnibus | individually_segregated
  cold_storage_min_pct: 0           # null/0 where the regime sets no numeric floor
  reconciliation: monthly           # daily | weekly | monthly
  signing_quorum: 2                 # minimum key-shares to authorise a movement
  key_holder_residency: []          # jurisdictions where signatories must reside

profiles:
  vara:                             # Dubai - VARA Custody Services Rulebook
    <<: *defaults
    reconciliation: daily
  mica:                             # EU - MiCA Art. 75
    <<: *defaults
    segregation_model: individually_segregated
    reconciliation: daily
  mas:                              # Singapore - PS Act, DPT service providers
    <<: *defaults
    cold_storage_min_pct: 90        # >= 90% of client tokens in cold wallets
    reconciliation: daily
    key_holder_residency: [SG]      # movement controllers resident in Singapore
  fca:                              # UK - proposed regime, CP25/14 (verify on finalisation)
    <<: *defaults
    reconciliation: daily

# Resolver rule per field (applied over all active profiles):
#   cold_storage_min_pct    -> max
#   reconciliation          -> shortest interval (daily wins)
#   segregation_model       -> individually_segregated wins over omnibus
#   signing_quorum          -> max
#   key_holder_residency    -> union of all constraints
#
# effective (vara+mica+mas+fca all active):
#   segregation_model: individually_segregated
#   cold_storage_min_pct: 90
#   reconciliation: daily
#   signing_quorum: 2
#   key_holder_residency: [SG]

The effective block is the platform’s actual operating posture. Turn off the Singapore licence and the residency constraint and the 90% floor fall away automatically; the codebase never changed. That is the property you are buying: regulatory scope becomes a data question, and adding a fifth jurisdiction is a new profile plus a resolver test, not a new build. The broader operating model this sits inside is one I have written about for multi-regulator VASPs, and the cold, warm and hot split it configures is the same one covered in custody architecture for a licensed CASP.

What a supervisor will actually test

A single effective configuration is only defensible if you can prove it was in force. So the profiles and the resolved config are versioned artefacts, change-controlled, tied to the release that ran under them. When VARA’s technology and custody audit team asks how you demonstrate segregation, the answer is not a slide; it is the profile, the resolver test suite, and the reconciliation logs showing the daily cadence held. The evidentiary discipline behind that is the one I set out in the VARA custody audit, and it carries across to the register-of-positions and Travel Rule obligations that ride alongside custody in multi-regulator VASP operations.

The failure mode to design out is silent drift: a regime tightens a floor, the profile is not updated, and the platform quietly operates below the line for a quarter before anyone notices. Make the resolver fail closed. If a profile references a field the resolver does not understand, or a numeric floor exceeds what the wallet policy engine can enforce, the deployment should refuse to start rather than run under an assumption nobody checked.

Four rulebooks do not need four platforms. They need one platform that is honest about which rule is currently the hardest, and a config layer that makes that answer inspectable. Fork the data, never the code.