
TL;DR
SMA demand is growing, but running separate digital-asset portfolios at scale creates a different problem: account capacity. Every client needs a separate book, with its own transactions, positions, cost basis, P&L, risk, and reporting. Add multiple chains, exchanges, and DeFi protocols, and the operational workload grows quickly. The solution is a software layer that lets SMA fund managers stay on top of all the accounts without multiplying the work.
In recent years, assets managed through Separately Managed Accounts (SMAs) have grown rapidly across traditional finance. The once-niche market managed an estimated $2.2 trillion in assets in 2023, with that figure projected to reach $3.6 trillion by 2027. The growth reflects increasing demand from investors for more bespoke financial solutions rather than one-size-fits-all products. [1] [2]
Digital assets have begun to develop the same model. Yet for an industry that has adopted financial innovations at remarkable speed, SMA adoption has been surprisingly slow. The problem isn't demand. It's the infrastructure required to manage separate portfolios at scale.
For a digital-asset manager, the appeal of SMAs is clear. They can give investors individually managed portfolios while allowing them to retain ownership of their assets. They also give managers a structure that can support different investment criteria without putting every client into the same pooled vehicle. However, this becomes a problem when the number of accounts grows.
Managing five separate portfolios is doable. Keeping track of the information trail each one leaves behind is annoying but manageable. Now imagine managing fifty. The accounting workload alone becomes an operational nightmare. And that's just the inconvenience. The bigger problem is maintaining and monitoring fifty separate risk profiles, each with its own exposures, constraints, and portfolio history.
Digital-asset portfolios already span fragmented infrastructure. One book can include assets across several blockchains, CEXs, lending protocols, liquidity pools, and other DeFi positions. Each platform has its own transaction structures, position models, and data conventions.
Now add multiple accounts to that equation. The manager needs to know not only what happened and where it happened, but also which client's book it belongs to. That distinction becomes critical when calculating P&L, cost basis, and NAV. This often means maintaining several spreadsheets just to keep the books straight.
It is tempting to think that what we face here is a scaling problem. But the real issue is the compounding nature of operational complexity. A manager can’t run one master portfolio and split the results across clients afterward. Each SMA has its own assets, transactions, and, most importantly, investment mandates. Hence, the separation has to exist throughout the portfolio's lifecycle.
But this would require a system that understands which account owns each position, where the transaction came from, how it affects that account's cost basis, and how it should appear in its reporting. If we try to maintain that separation manually, every new account rapidly increases the operational work.
This compounding of operational overhead creates an unusual constraint for asset managers. A manager may be capable of managing 100 clients, but the operational capacity may restrict them to manage only 20. Such a business then has three choices: stop taking new accounts, hire more operations staff, or accept more manual processes and also the risks that come with them.
The broader alternatives industry shows what technology can change. Data from Datos Insights estimates that manual processes can support roughly 200–250 positions per operations employee, compared with more than 3,000 positions in technology-enabled environments. Technology-enabled quarterly closes can also take around 15 days versus two to three months manually. The exact numbers may vary by firm, but the trend is clear: operational infrastructure determines how many portfolios a team can support.
This operational challenge is especially pronounced in digital assets because even within a portfolio, there’s too much fragmentation. DeFi funds can have positions across multiple chains, centralized and decentralized exchanges, and several different protocols. The positions are not yet standardized. Transactions can include swaps, deposits, withdrawals, LP activity, lending, borrowing, staking, and other events. Some positions are straightforward, like token balances; others are represented by protocol-specific objects, like a liquidity position in Uniswap V3.
A digital asset management platform therefore needs to do more than aggregate wallet balances. It needs to reconstruct the portfolio accurately from the underlying activity. And for an SMA, it needs to do that separately for every account.
For an SMA manager, a useful portfolio management system should provide a consistent view across three levels:
The business: How much capital is being managed? Where is the aggregate exposure? How is the overall book performing?
The account: What does each client own? What are their P&L, cost basis, NAV, and risk exposure?
The granular details: Which transactions created those positions, and can the resulting numbers be reconciled back to the source?
That last layer really matters. A simple portfolio dashboard is useful, but a dashboard that cannot explain where its numbers came from eventually becomes another system that the operations team has to reconcile. The ideal digital assets portfolio management software should support portfolio management, risk monitoring, accounting, and reporting with real-time data.
Hence, the right architecture is therefore not one large portfolio with manual divisions added afterward. Instead, it should be one manager interface connected to many genuinely separate books. The manager should get a consolidated view across the positions, while each SMA retains its own portfolio context, transactions, performance, and reporting history.
That allows the investment team to move between the aggregate book and an individual account without reconstructing the information each time. It also makes the operating model more scalable. Adding a client should add only one new portfolio. Adding a client should add one new portfolio, not another collection of spreadsheets and manual reporting workflows.
Portfolio visibility is only a part of the problem digital asset fund managers face. Every transaction changes the financial history of an account. It can affect cost basis, realized and unrealized P&L, NAV, and future reporting. For an SMA manager, these records cannot simply be consolidated at the fund level. They need to remain attributable to the individual client.
That is why portfolio management and digital-asset accounting are increasingly connected. If the underlying transaction record is reliable and account-specific, it can support portfolio analysis, accounting, and reporting without repeatedly rebuilding the same information.
Risk needs the same separation. Aggregate exposure can tell a manager where the overall business is concentrated, but it can hide what is happening inside each account. Some clients may have substantial exposure to an asset or protocol while others have none. One account may have lending positions, while another is entirely spot.
A useful digital asset risk management system therefore needs to work at both levels: across the manager's entire book and down to each individual account. The goal is a consistent view of exposure from all angles.
CROPR solves this. It works as a read-only digital-asset operating and intelligence layer. Funds can connect the wallets and accounts they manage, and CROPR reads and organizes the transaction and portfolio data from those sources. That data can then be used across portfolio management, risk analysis, accounting, reporting, and AI-powered workflows. For an SMA manager, this means maintaining account-level separation while getting a consolidated view of the entire business.
Instead of reconstructing each book manually, managers can work from a common view of portfolio activity, positions, and performance across their accounts. All of these can be done without giving up custody of client assets. That creates a foundation for portfolio management, risk analysis, P&L, accounting, and reporting, without giving up custody of client assets.
Read more about how CROPR addresses operational inefficiencies in on-chain market making.
SMAs are only one example of a broader infrastructure problem. For digital-asset managers of all types, running sophisticated strategies across several chains, protocols, and counterparties can eventually make the operational layer the bottleneck. That means a fund's investment capacity can ultimately become limited by its account capacity.
The next generation of digital-asset management infrastructure will not simply help managers see more data. It will help them operate more portfolios without turning every additional account into another operational burden. That is the real opportunity for SMAs.
Request a demo: institutional@cropr.finance
Each SMA needs its own transaction history, positions, cost basis, P&L, risk, and reporting. Multi-chain portfolios and fragmented DeFi and exchange data make maintaining that separation more difficult.
Not in the sense of treating the accounts as one pooled portfolio. Each SMA is a separate book. Transactions and positions need to remain attributable to the appropriate client account throughout the portfolio lifecycle.
It should consolidate portfolio and transaction data while preserving account-level separation. At minimum, managers need reliable positions, P&L, cost basis, NAV, exposure, and historical transaction data for each account.
CROPR is read-only. It reads transaction and portfolio information from connected wallets, exchanges, and protocols and organizes that information into a consolidated view while preserving the underlying portfolio context.
No. CROPR does not execute trades or move client assets. It reads and analyzes the information generated by activity across connected digital-asset platforms.
Because operational workload can become the limiting factor on growth. A manager may have the investment capacity to take on more clients but lack the systems to maintain separate books, reconcile transactions, and produce account-level reporting efficiently.