The 7 Custody Questions Your Users Will Ask, And How to Answer Them Clearly

TLDR: Every crypto onboarding conversation eventually includes "wait - where is my money actually stored?" Most founders either over-explain the tech or give vague answers that create more anxiety than they resolve. This guide walks through the 7 questions your users will actually ask, what each one is really probing for, and how to answer clearly without losing them in cryptography.

Why this question hits different

There's a version of every infrastructure question that's about cost and scale. This isn't one of them.

Users who've lived through Mt. Gox, QuadrigaCX, and FTX — or just read the headlines - have one thing burned into memory: custody failures mean losing everything overnight.

So when a user asks "how do you handle keys?", they're not evaluating your cryptographic choices. They're asking whether their funds can survive a bad day.

"Users are not asking out of curiosity. They are deciding whether to trust you with their money."

The good news is you don't need to be a CTO to answer well. You need to understand your architecture at a conceptual level, know where the risks sit, and be able to explain your choices without flinching. Here's how.

The 7 Questions Your Users Will Ask About How You Handle Their Funds

Private key ownership

What they're really asking: Is there a single point of failure that can wipe out my funds overnight?

A private key is the cryptographic secret that authorizes moving funds. Whoever holds it, controls the assets. Three main approaches exist in the market today:

• Third-party custodian. A regulated firm like Fireblocks, Cobo, or BitGo holds keys on your behalf. Fast to implement, comes with established compliance pedigree, but you inherit their pricing, uptime risk, and roadmap.
• Self-hosted. You run key management on your own servers. More control, more responsibility, requires internal security maturity.
• Self-hosted MPC - Fystack. Private keys are never stored in complete form anywhere. They are cryptographically split into encrypted "shards" distributed across multiple independent parties. No single shard can sign anything. Moving funds requires a quorum, say 2 of 3 or 3 of 5 parties, to cooperate.

One practical edge worth mentioning in this answer: because MPC operates at the cryptographic layer rather than the smart contract layer, it works natively across Bitcoin (ECDSA/Schnorr), EVM chains, and non-EVM ecosystems without bridges or chain-specific adapters. Investors evaluating multi-chain exposure notice this.

If you run self-hosted MPC, your one-sentence answer to users is: "No single person, server, or breach - including us - can move your funds unilaterally. Every transaction requires multiple independent approvals by design."

Company survival risk

What they're really asking: If your company shuts down tomorrow, do I lose my funds?

This question is part regulatory, part business continuity. Users are really checking three things:

• Are my funds kept separate from your company's money?
• Would I lose access if you went bankrupt or got acquired?
• Is there a way to recover my funds that doesn't depend on you still being around?

In Singapore (MAS DPT framework) and Hong Kong (SFC VASP licensing), segregation of user assets is increasingly a hard legal requirement, not just a best practice. Sophisticated users, and the journalists who cover crypto collapses, know this.

For self-hosted infrastructure, the clean answer is that key material and signing infrastructure can be handed to users or a designated trustee independently. The cryptographic protocol does not require the company to remain alive to function.

"The cryptographic protocol does not require the company to be alive to function."

Third-party security audits

What they're really asking: How do I know you're not just telling me what I want to hear?

The answers users find credible, in order: Independent security audits by recognized firms - not internal reviews - with results you're willing to share. SOC 2 certification or equivalent operational security standards. Public audit reports, even summarized ones. A clear statement of what has and hasn't been tested.

If you don't have these yet, be direct with users about your timeline. That's more credible than silence. What erodes trust fastest is "our team reviewed it internally" - users who've seen exchange collapses know exactly what that means.

Preventing unauthorized signing

What they're really asking: Can one rogue employee drain wallets?

In a traditional hot wallet setup, a small number of administrators have signing access. Security is almost entirely a function of trust and process. One compromised credential, one disgruntled engineer at 2am, that's your exposure window.

MPC changes this at the architectural level, not the policy level. No single employee can unilaterally sign a transaction because:

• No complete key exists anywhere. Shards are cryptographically independent.
• Zero-knowledge shard design means even an engineer with root server access sees only an encrypted fragment, nothing usable.
• Quorum enforcement means moving funds requires N of M independent approvals across separate parties or devices.

Complementary controls investors want to see alongside MPC:

• Role-based access control (RBAC) with immutable audit logs
• Hardware Security Modules (HSMs) for shard storage (purpose-built physical devices that prevent key extraction)
• Velocity limits and destination whitelist policies on transaction signing
• Out-of-band approval workflows for high-value transfers
• Gas sponsorship policies that let the application cover transaction fees on behalf of users, removing the requirement for users to hold native tokens, without touching the underlying key distribution

Founder note: A pattern that comes up repeatedly in post-mortems: a platform's withdrawal signing depended on a single engineer with no hardware isolation and no documented recovery process. The platform didn't fail because the team was incompetent - it failed because the architecture couldn't survive that person leaving or being compromised.

If you want to go deeper on how MPC wallet architecture handles all of this under the hood, our MPC wallet overview for startups and institutions covers the core concepts without requiring a cryptography background.

Licensing and regulatory status

What they're really asking: Is this platform actually legal where I live, and am I protected if something goes wrong?

Be precise and honest. Name the jurisdictions you operate in, what license or exemption you hold, and where you are in the process. Users increasingly Google this, and find the gaps.

The table above covers the key frameworks. A few things worth knowing before you walk into the room:

In Singapore, the MAS DPT regime distinguishes between a Standard Payment Institution (SPI) and a Major Payment Institution (MPI), with the MPI license required once you exceed certain transaction volume thresholds. Many early-stage teams operate under an exemption while the MPI application is in process; that's fine to say, just say it accurately.

In Hong Kong, the SFC VASP license now mandates specific requirements around how custody is handled, including approved arrangements for cold wallet storage. Your custody architecture directly affects your licensing pathway, not just your security posture.

Under MiCA in the EU, CASP (Crypto Asset Service Provider) registration requires demonstrating custody safeguards at the documentation level, which means your key management procedures need to be written down, version-controlled, and auditable.

If you're pre-license in any jurisdiction, the right answer is: "We are operating under [specific exemption or basis] while our [license type] application is in process, expected [timeline]."

Custodian dependency and SLAs

What they're really asking: What happens to my funds if your infrastructure partner disappears or goes down?

: If you use a third-party custodian, users will eventually ask: What happens to my funds if that vendor has extended downtime, gets hacked, or exits your market?

The honest version of this conversation includes acknowledging that third-party custody has legitimate advantages, particularly for early-stage teams: established compliance frameworks, proven infrastructure, and reduced internal operational burden.

For a team that doesn't yet have dedicated security personnel, outsourcing custody may genuinely reduce risk despite introducing vendor dependency. That's a real tradeoff, not a weakness.

The counter-argument for self-hosted: no pricing dependency as volume grows, full ownership of the audit trail regulators require, and chain coverage that follows your product roadmap rather than a vendor's. Because MPC operates at the cryptographic layer, adding support for a new chain, including native Bitcoin, Solana, or emerging non-EVM ecosystems, doesn't require a bridge or smart contract. That matters to investors evaluating your ability to follow market demand.

If you want to go deeper on the infrastructure tradeoffs, Fystack has a breakdown comparing self-hosted vs. third-party custody models. Fystack vs. Cobo pricing breakdown.

Disaster recovery

What they're really asking: If a catastrophic event hits, do user funds survive?

Fire, cloud termination, team exodus, a legal hold on your accounts. Your users need to know their funds survive all of these - even if they'd never phrase it that way. What they're looking for:

• Geographic distribution of key shards across separate data centers and jurisdictions
• Offline backup procedures (HSMs in separate physical locations, documented paper key ceremonies)
• A recovery runbook that has been actually tested, not just written
• A threshold configuration that allows full recovery even if one shard holder is permanently unavailable

In an MPC setup, a 3-of-5 configuration means any three of five designated parties can restore signing capability without a complete key ever existing during recovery. That's the answer investors want to hear: recovery is possible, it doesn't require reassembling the full key, and no single party becomes a recovery bottleneck.

Have an architecture diagram ready for the data room. Founders who can walk through disaster recovery in concrete, visual terms signal a level of operational maturity that verbal descriptions rarely convey.

For an overview of how the full architecture fits together, our comparison with Fireblocks walks through the self-hosted model versus SaaS in detail.

How custody architecture maps to what investors are actually scoring

Every question above is measuring the same four variables. Once you see the pattern, preparation becomes much more structured:

Before your next user conversation: quick checklist

• Can you name who holds key material and in what configuration?
• Does a single person, server, or vendor failure put funds at risk?
• What is your audit status and your honest timeline if incomplete?
• Which jurisdictions are you licensed in, under which specific framework?
• Do you have a tested disaster recovery procedure?
• Can you produce a custody architecture diagram in the data room?
• If you use a third-party custodian: what is your documented exit plan?

Most founders stumble on questions 2 and 5. Walking through all seven clearly puts you ahead of most rooms.

FAQ

Fystack is self-hosted MPC custody infrastructure for crypto businesses that need institutional-grade key security without vendor lock-in. If you're preparing for investor due diligence and want to review your custody architecture, get in touch.