Giving portal for ultra-high-net-worth clients — crypto-enabled

• 01

  The advisor–trustee–compliance signature chain is legally required — authorization rules were set by legal and risk and could not be removed, only re-sequenced.

• 02

  Tax reporting and cost-basis handling had to be intact and visible at commit for any asset type, including crypto.

• 03

  Only Vanguard-vetted recipients could be offered — discovery is a curated shortlist by design, not an open directory.

• 04

  Advisor oversight had to stay in the loop; nothing could bypass the people clients already trust.

I decided the interaction model and recommended the parallel authorization pattern. Authorization and compliance rules were set by legal and risk.

1. 01

   Cause-first entry, not search-first

   Observed problem

   UHNW clients don't shop for charities — they name a problem ("hunger in Sub-Saharan Africa") and expect vetted options. The inherited flow opened with a retail-style search box.

   Constraint

   Only Vanguard-vetted recipients could be offered, so the discovery surface had to be a curated shortlist, not an open directory.

   Decision

   I replaced search-first discovery with cause-first entry: the client starts from the problem they care about and lands on a shortlist of vetted trusts, foundations, and NGOs.

   Tradeoff

   Clients see only the vetted set rather than the full universe of charities — a narrower surface, chosen deliberately because vetting is the trust guarantee.

   ResultRegulator status and disbursement history are visible before the client opens a profile, so the trust decision happens on-screen, not in a follow-up call.

   I decided the interaction model; engineering and compliance delivered the vetting data behind it.

2. 02

   Bitcoin as a first-class rail

   Observed problem

   These clients held appreciated crypto and securities, but the giving flow only supported cash on slow ACH rails — the asset types they actually wanted to give had no path.

   Constraint

   Tax reporting and cost-basis handling were non-negotiable for legal and risk; nothing could ship without them visible at commit.

   Decision

   I pushed for Bitcoin alongside cash and securities in the primary flow — not a secondary path — with live conversion and network-fee transparency shown before authorization.

   Tradeoff

   Adding a crypto rail put conversion, fees, and cost-basis math into the primary flow, which made the commit step denser to design and explain.

   Result~$49M moved via Bitcoin across the first cohort, with the full cost-basis and tax packet auto-delivered to the client's CPA on settlement.

   I decided the flow and commit-screen hierarchy; the crypto custody partner and tax teams owned the underlying rails.

3. 03

   Parallel authorization instead of serial signatures

   Observed problem

   Every gift routed through a serial signature chain — advisor, then trustee, then compliance — so a seven-figure gift took roughly four months and nobody could see where it had stalled.

   Constraint

   The signature chain itself was legally required; authorization rules were set by legal and risk and could not be removed, only re-sequenced.

   Decision

   I recommended a parallel authorization track: advisor, trustee, and compliance co-sign in flight while the client watches each authorization arrive in real time.

   Tradeoff

   Parallel signing created more concurrent states to design and keep auditable — the interface had to show who had signed, who was pending, and preserve the full chain.

   ResultTime to disperse funds to a client's chosen causes fell from ~4 months to ~6 weeks, with 100% signature-chain preservation on every transaction.

   I recommended the pattern and designed the status surface; legal and risk defined the authorization rules it had to satisfy.

Project status is shipped. All screens are reconstructions; reconstruction is a visual disclosure only and does not verify the figures above.