Crypto Portfolio Optimization Engine
The client operated a retail crypto investing platform with roughly seventy thousand active accounts and a thesis that retail investors underperformed the market because they rebalanced reactively and inconsistently. The product offered hand-picked basket portfolios but had no automated rebalancing, so investors who set an allocation in January found themselves with very different risk exposure by April after market drift, and most users did not log in often enough to correct it.
Trading, FinTech & Analytics
Crypto/Investments
14 weeks from kickoff to general availability
4 specialists
The full story
The practical problem was that automated rebalancing in crypto was not just allocation arithmetic. The asset class carried distinct microstructure — wide spreads on smaller tokens, fee schedules that varied by exchange, and weekend-and-holiday liquidity gaps — and rebalancing without accounting for these produced trades that cost investors more in execution drag than the rebalance was worth. Existing portfolio-management tools were equity-first and did not model crypto microstructure well.
We built a portfolio optimization engine that took each investor’s risk-tolerance profile and target allocation as inputs, monitored portfolio drift continuously, and proposed rebalancing trades that accounted for spreads, fees, and liquidity per asset. The optimizer ran a constrained mean-variance approach with risk-tolerance bands rather than point targets, which reduced trade frequency and cost while keeping investors near their intended exposure.
What shipped was an opt-in automated rebalancing service that proposed trades for investor approval (with a fully-automated tier for premium accounts), monitored drift continuously, and adapted to changing volatility regimes by widening or tightening the tolerance bands. Average portfolio return on opt-in users moved positive relative to the holdout cohort, and the platform’s premium tier saw a notable uptake from users who specifically valued the hands-off rebalancing.
Retail crypto investors set allocations and forgot them, then watched drift erode their intended risk profile within a quarter.
Manual rebalancing required regular logins that most retail users did not perform, so allocations drifted from target unchecked.
Equity-first portfolio tools did not model crypto microstructure, producing rebalance trades whose costs erased the rebalance benefit.
Spreads, fees, and liquidity varied by exchange and by token, so naive rebalancing instructions performed worse than no rebalancing.
Volatility regimes in crypto shifted faster than equity portfolios, so static rebalancing tolerance bands either over-traded or under-corrected.
No way for the platform to differentiate premium accounts with hands-off rebalancing made the upgrade path commercially weak.
How we structured the engagement
Built rebalancing as a microstructure-aware optimization, not as allocation arithmetic, so trades did not cost more than they saved.
- 01Phase 01Weeks 1-3
Discovery
Reviewed two years of platform trade history to taxonomize execution drag by token and by exchange. Interviewed twenty active users on their actual rebalancing behavior and frustrations. Output: a microstructure model per token, a risk-tolerance schema, and the design constraint that trade costs must be modeled inside the optimization.
- 02Phase 02Weeks 4-5
Architecture
Designed a constrained mean-variance optimizer that took target allocation, risk-tolerance band, and per-asset microstructure as inputs. Built a drift monitor that watched portfolio composition continuously and triggered the optimizer when drift exceeded the band. Used Binance and a second exchange for execution with a routing layer per asset.
- 03Phase 03Weeks 6-11
Build
Shipped the microstructure model and the optimizer first because allocation logic depended on them. Built the drift monitor, the approval flow for non-premium tier, and the fully-automated tier for premium accounts. Implemented regime detection on rolling volatility that widened or tightened tolerance bands automatically.
- 04Phase 04Weeks 12-14
Launch
Rolled out to five thousand opt-in users over six weeks, monitored execution drag per rebalance and the difference between proposed trades and naive rebalancing. Tuned the regime detector based on the March volatility spike that occurred during rollout. Promoted to general availability after the cohort outperformed the holdout consistently.
What we built, component by component
- 01
Microstructure model
Per-asset model of spreads, fees, and liquidity across supported exchanges, refreshed throughout the trading day.
- 02
Drift monitor
Continuous watcher on each portfolio’s composition that triggers the optimizer when drift exceeds the tolerance band.
- 03
Optimizer
Constrained mean-variance solver that proposes rebalancing trades within tolerance band, accounting for trade cost in the objective.
- 04
Regime detector
Rolling volatility classifier that widens tolerance bands in high-volatility regimes and tightens them in low-volatility regimes.
- 05
Execution router
Routes proposed trades to the best-priced exchange per asset, with retries and fallback logic for partial fills.
- 06
Approval surface
Investor-facing approval flow for standard tier and automatic execution path for premium tier with notifications.
The drift monitor watches each portfolio continuously against its tolerance band, which the regime detector adjusts based on current volatility. When drift exceeds the band, the optimizer proposes rebalancing trades that minimize execution drag against the microstructure model, the execution router places them across exchanges, and the approval surface gates execution for standard-tier accounts while running automatically for premium accounts.
The trade-offs we made and why
Modeled trade cost inside the optimization objective
Treating trade cost as a post-hoc filter on rebalance proposals produced trades that looked good on paper and lost money in execution. Modeling cost inside the objective gave the optimizer the ability to trade smaller amounts more often or larger amounts less often based on which minimized total drag.
Used tolerance bands rather than point targets
Point targets generated trades on every small drift, accumulating execution drag that overwhelmed the rebalance benefit. Tolerance bands let the portfolio breathe within an acceptable range and only triggered rebalancing when drift was material, which improved net performance.
Built regime-adaptive bands rather than static ones
A band tuned for low volatility over-traded in high-volatility regimes; a band tuned for high volatility under-corrected in calm periods. Regime detection on rolling volatility let bands adapt automatically, which kept the rebalance frequency appropriate across market conditions.
Approval flow for standard, automatic for premium
Forcing approval on every trade for non-premium users matched their expectation that they were still in control, while premium users specifically wanted hands-off operation. Differentiating the tiers gave the platform a commercially meaningful upgrade path and matched user expectation per segment.
What changed for the client
average returns
Average portfolio return for opt-in users versus the holdout cohort over the first six months after rollout.
execution drag
Reduction in trade-cost-as-percent-of-rebalance-value versus naive rebalancing across the opt-in cohort.
drift monitoring
Replacement for the prior manual-rebalance model, with drift monitored every market update and bands adapting to regime.
premium tier uptake
Increase in premium-tier subscriptions during the first quarter post-launch, attributed by the team to hands-off rebalancing.
The tools behind the system
Built with a deliberate stack chosen for production reliability and operational velocity.
Lessons learned from the build
Modeling trade cost inside the optimizer rather than outside it was the single change that made the system work. We almost shipped a cleaner two-stage design that filtered trades after optimization, and the first week of cost analysis would have shown that approach losing money. Trust the math earlier next time.
Regime-adaptive bands were what made the system robust to the March volatility spike that hit during rollout. A static-band system would have either over-traded through the spike or held the portfolio off-target through it. The regime detector earned its complexity in week thirteen.
Tier-based interaction patterns mattered as much as the optimization quality. The same engine with the same trades would have produced churn if forced on standard-tier users without approval and would have produced complaints if held back from premium users. Matching the interaction to the segment was as much product work as engineering work.
Similar delivery work usually starts in these service areas
If you are exploring a similar product, workflow, or implementation challenge, these are the service tracks that usually fit best.
Where this project sits in the bigger market picture
How we approach AI delivery for payments, banking, underwriting, and financial workflows.
Build a result-driven AI product with a team that has shipped before
If you are exploring a similar product, workflow, or AI use case, we can help scope the right architecture, delivery model, and first milestone.
Related case studies worth reviewing next
Have an AI idea, messy workflow, or product vision? Let's make it buildable.
Bring the problem. We'll help shape the product, define the architecture, and show the fastest path to a serious first version.
A practical first roadmap in the discovery call
Architecture, timeline, and delivery options in plain English
Security, scalability, and reliability discussed upfront
Model registry
softus-rag-v4.2
187ms
Latency
128k
Context
$0.004
Cost / req
Evaluation suite
Deploy pipeline
prod / canary 25% — healthy