VP of Product at iCapital on streamlining alternative investment administration

We spoke with a former VP of Product at iCapital who led initiatives to streamline alternative investment administration for wealth managers and fund managers.

The conversation explores how iCapital's platform automates complex post-trade activities, fee calculations, and reporting while examining the potential for distributed ledger technology to transform data reconciliation across the alternatives ecosystem.

Key points via Sacra AI:

What problem does iCapital most decisively solve for wealth managers and RIAs on one side? And GPs on the other?

The main problem that iCapital solves for wealth managers and RIAs is managing the feeder fund business into alternative investment funds that they were previously managing in-house. This includes everything from setting up the funds, making sure the fee structure they're negotiating with the underlying fund managers matches, and handling the end-to-end administration in fund management. This covers the subscription onboarding process, KYC/AML procedures, allocations, investor reporting, document generation, and sending them to a document repository, emailing those out in a compliant way to all the end advisers and their investors.

There's a lot of manual administrative work that each of these wealth managers and RIAs was managing before that didn't really make sense or scale over time. iCapital not only becomes the GP of those feeder funds and takes on that admin burden in exchange for a management fee, but also builds custom technology solutions that serve essentially as a one-stop shop for advisors and their investors. They can log in, subscribe into multiple funds, and manage all their documents and reporting in one platform.

On the GP side, these underlying fund managers want to distribute through the wealth manager and RIA channels. To do that, they set up custom feeder funds. The underlying fund managers don't want to independently distribute to all end investors—they want a couple of institutional feeder funds that they can set up. It's actually beneficial to them to have iCapital be that one intermediary that can then distribute to all these channels. For the GP, iCapital serves as one investor, and that one investor represents all these wealth managers, RIAs, and their individual clients.

Out of that stack, which parts did you see as the most painful for wealth managers to manage alone? Where did iCapital deliver the most noticeable lift or time savings?

The biggest burden for the wealth managers is in post-trade activities. Let's say that you have hundreds or thousands of end clients and each of those end clients has to have individual post-trade reporting and allocation across each of their funds. Anything that is post-trade is post subscription. After your initial subscription, you can have individual redemptions and transfers. For open-ended funds, you have monthly NAVs that need to be calculated down and reported, and then those values need to be structured into documents that need to be sent to each investor.

For closed-end drawdown funds, you typically have quarterly P&Ls, which have different allocation and reporting. On an annual basis, you have to generate the tax K-1 documents or 1099s and make sure they're sent out and administered on an ongoing basis.

Each of the funds is also different—different tax providers, different audit providers. If there's any issue that the end investor needs to submit for any individual position or across their positions, you need someone to manage all of that back and forth across that post-trade life cycle.

Can you give an example of how iCapital's platform helps standardize or automate a process in that post-trade phase? Say, for tax documents or NAV allocations across multiple underlying funds with different administrators?

If I double click on that tax requirement—because every single fund needs to have annual tax reporting—what iCapital's platform does is structure the data at the fund level and identify the type of tax reporting that each fund requires, whether it's a K-1 or a 1099, and which tax provider will be servicing the taxes for this fund this year.

In order to manage the tax documents for one fund, we have structured the data, set up the type of tax reporting, and identified the tax provider. At year-end, we have to send 100% of the monthly NAV data for that fund for each investor, including all of the fees, expenses, and capital activities to the tax provider, as well as the demographic information and books and records for all of the investors in that fund.

The tax providers will calculate the documents and send them back to iCapital. We will make sure from an operational perspective that 100% of documents are represented before they're sent out by the deadline to investors. All of that data aggregation, data maintenance over the entire year, reporting, and the back and forth with the tax provider is managed through iCapital's platform through structured data, API integrations, and the operational flow of validating all of that information before the wealth managers even have to jump into the process.

What happens when something goes wrong, for example, a missing K-1 from a tax provider, or an error flagged at the adviser level? How does iCapital handle those kinds of exceptions or disputes in the post-trade reporting cycle?

Either iCapital's data integration or our platform logic will catch issues. For example, if there are 2,500 accepted investments in a fund and we only received 2,498 K-1s for that fund, our portal will flag that. Someone on the iCapital operations team who logs into that platform will then reach out to the tax provider and say, "Here are the two investors that were not found in your zip file of documents. We mapped that down to the underlying investor ID. That's how we know who's missing. You either owe us these documents or something was wrong in the way that you received the reporting for the fund. How do we reconcile the data issue?" Once that's fixed, it'll be reuploaded into our platform before it's published to the end investors.

When you think about overall distribution volume on the platform, which channels drove the most flows in your experience? Were warehouses dominant, or were independent REAs and wealth managers key contributors to net new volume as well? And if you can rough scale or share of each, even directional, would be great.

Within the iCapital universe, the wirehouses were clearly dominant. Rough scale, I would say over 80-85% of the business was driven by the wirehouses, then came the RIAs, and then individual investors, but that made up a very small portion of the pie.

Within that warehouse segment, did you see differences in requirements or workflows that shape the product? For example, around document delivery, entitlement logic or fee splits, versus independent RIAs. How did warehouse demands materially change what iCapital had to build or support?

Large wirehouses and large RIAs acted very similarly to each other. But if you take into consideration the globally largest wirehouses—there are about 4 big players globally—they are much tighter in their custom branding requirements than other firm types might be.

For the globally largest wirehouses, they were the strictest in their requirements. Either we had to route 100% of our logic, branding, and even email sending through the warehouse's third-party site so they could control 100% of their client experience. Or if there's anything that the end client at those wirehouses needed to access directly from iCapital, whether through our website, documents, or emails, it was completely customized branding to that wirehouse.

Tier 2 of our clients were smaller wirehouses or large RIAs that acted very similarly to each other. They were more like, "We want our clients to log in to the iCapital universe of products. We want them to get their emails from you. But we do want it to be branded with our brand, our logo, our colors, and our language," but that's kind of out-of-the-box customization. The smallest shops were much more flexible, saying "just use the iCapital universe because we don't have our own custom technology anyway."

You supported these deeply branded workflows for warehouses. Did that affect things like versioning or document packaging in the adviser portal? For example, did different branding tiers require different PDF templates or content logic for post-trade documents?

We have the ability for any customer to customize the template per post-trade document type, including at the fund level. Even if you're one wirehouse or one RIA firm, you're setting your own header, footer, logo, and can set your own email template as well as the placeholders or macros that you're using within that email template.

You can determine what numbers are aggregated and in what way you want to display them, at what cadence, for what email type. Do you want to consolidate your emails into one big email, or do you want to send them in real time? What time of day do you want to send the emails? All of that was completely customizable within the platform.

How did iCapital approach advisory and management fee calculation for feeder funds distributed through managers and REAs, particularly when fee schedules could vary by channel, even by investor group?

The way that the iCapital fee structure was set up—we had acquired the feeder fund business from a lot of these wirehouses and RIAs, so we inherited the ways that fees were set up, including the payout schedule, inside/outside fees, whether they were smoothed or not, whether they were paid in advance or in arrears. All of that was already inherited.

Even with new funds that we set up, from a legal fee structure perspective, we kept that consistent with how the distributors were setting up their fees, and then we swapped in the standard iCapital management fees.

In terms of how we manage the fees, we built a custom product for fee calculation. It essentially says for each fund, you can set up fees in a tiered logic perspective. You can say there's a fund-level fee, a share class level fee, a firm-level fee, brokerage versus advisory fee, investor-level fee, fees that flip on a certain date. For each fee you can configure: Is it outside or inside? In arrears or in advance? Is it commitment-based or NAV-based?

We built this fee calculation tool that allowed you to set up fees at any granularity level. The more specific a fee is, the higher it ranks against any other fee that is set up for that fund. When you calculate fees, you can say, "I have an overarching management fee and overarching trail fee. I have a custom firm fee per distributor that flips on a certain date," and so that all matches the way that the fees are legally set up within the fund's terms.

What kinds of data inputs were essential to drive accurate fee calculation in this model? And what pipelines needed to be solid underneath that tool?

In terms of the pipelines that needed to be set up, we did have fee breakpoints like minimum commitment, maximum commitment per breakpoint. For the fee engine to run, you need the fund set up with at least one fee. Within that fund, you need accepted investor data, including their commitment amounts, to be set up with certain investment flags.

If it's a commitment-based fee, that could be the minimum needed. If it is a NAV-based fee, the fees will calculate based on the last available reporting period for that NAV. So you need the NAV table to be set up including report date and published NAV per accepted investment in that fund.

If you have firm-level fees, you need each investment to be associated with the firm ID. If you have very generic fees that are set up for a fund, all you need is accepted investments and you should be good to go. If you have specific fees that are set up tied to any underlying data, that underlying data needs to be published and accepted for that fund in order for that match to calculate something. For example, if you have firm-level fees but no firm-level data against any investment in that fund, you won't see any fees calculate.

When it worked smoothly, what did you use to validate and audit fee outputs? Were there reporting tools or reconciliation routines so internal teams or partners could trust or challenge the numbers?

That wasn't fully built by the time I left. The short answer is that was on the roadmap and not yet fully built.

Initially, what was done was that the internal fund finance and corporate finance teams were calculating fees in Excel before the fee calculation engine was even built. They were comparing their Excel files to the generated fees that were provided to us by the fund administrators.

Once this fee calculation tool was built out, our internal teams stopped needing to calculate fees in Excel files, but we were still manually comparing our calculated fees to those provided by our fund administrators and making sure that everything tied out. If things didn't tie out, anyone can drill down into what is breaking. Is it a fee per investor? Is it total fees that were charged at the fund aggregate level? Or is it something in between? Then we could identify the exact issue.

What was on the roadmap was to be able to ingest the fees provided by the admins, automatically compare them fee by fee and at the aggregate level with what was calculated by our engine. If it's all approved, show that as a flag where a human in the loop needs to approve it. If anything doesn't tie out, raise that as an issue that a human needs to go in, validate, and then resolve.

Let's shift briefly to distributed ledger technology. Why was DLT interesting in this context? What specific inefficiencies or mismatches were you trying to eliminate across fund life cycles or stakeholders?

The main goal of DLT was to essentially become the industry utility for alternative investments. Every individual firm, including iCapital but also any firm that we worked with, had anywhere from 10 to 300+ point-to-point integrations that were email-based, SFTP-based, or one-off API-based. For each integration, you're doing a one-off data mapping and trying to reconcile all of this data back and forth.

iCapital, especially sitting in the middle of a lot of these firms, would be maintaining a lot of the operational burden of data mapping, data maintenance, and data reconciliation. We knew that was leading to operational inefficiency across the entire industry.

With DLT, the goal was for everyone to only have to maintain one integration to one data standard. Then the source of truth of one piece of data or one document could control who gets to see it at what point in time, flow it through DLT as a utility, and then route it appropriately. Instead of saying I have to reconcile that same data point between myself, the underlying fund manager, the fund administrator, the tax provider, and the wealth manager, just the wealth manager can maintain it in their system, pass it through DLT, and have it distributed to the nodes of any downstream participant. That would spread across the entire ecosystem—300+ participants could all say, "I'm maintaining my data, I get to consume data across the entire universe, and I can do all of that through one data integration."

That paints a very compelling vision. A single integration into a permissioned network that wrote standard form data and documents to all downstream stakeholders. Within that vision, which specific life cycle events did you prioritize for initial DLT implementation? Was it NAVs, capital calls, K-1s, performance, something else?

We had initially started by wanting to focus on the post-trade calculations, so any capital activities, and then NAV and P&L calculations because that was where the highest volume of data is taking place and the highest operational burden is being felt across the ecosystem.

In practice, though, all of the post-trade reporting depends on the pre-trade data being set up—fund, share class, investor, contact information, all of that good stuff. Without that being set up, you can't do the post-trade, so we ultimately had to start at the beginning of the life cycle and then move through in a linear fashion.

With our initial partners, they were really focused on the initial subscription process, firm collaboration, and reconciliation, which is at the very beginning of the life cycle of a fund.

With that first DLT implementation, how did permissioning and privacy work? Who could see what? And how did you manage entitlement boundaries across the network?

We followed the structure of who is the data owner, then how does the data owner permission their downstream participants to access their data.

We know that no matter what, a GP owns a fund and all of the share classes against that fund. They should be the data owner, and they should control who gets to access their fund and each share class at what point in time. That's only going to be at the view level.

If you are a wealth manager with a wrapper against that fund, including side letter terms, then you can add your own wealth manager-specific fields to a fund, but you cannot edit the GP-owned data elements of the underlying fund. Each data point has an owner—wealth managers own their investor contacts and can set permissions at that level.

Zooming out, what was the biggest blocker to broader adoption of DLT during your time? Was it technical, legal, operational? Or just change resistance across entrenched players?

Change resistance across entrenched players, mostly related to an inability to move on an API integration at the speed that we needed to implement.

Looking 3-5 years out, what do you think the alternatives distribution space is about? Is it depth of integrations, breadth of fund access, lowest cost to serve, advisor NPS, or something else entirely?

If we look at it, there's a legal structure, a technology component, and an experience—those are the three buckets I really look at.

From a legal structure perspective, who owns the feeder funds and the relationships as the feeder fund GP with the distribution channels is a big part of what has brought iCapital to where it is today.

From a technology perspective, it's absolutely going to be who can make it as low-touch as possible for anybody to manage their end-to-end alternative investments but also integrate that with their public assets. We started to see a bigger push for a one-stop shop reporting solution with a client's entire portfolio across not just alts and structured products, but public assets and equities as well. How does that integrate into the rest of the stack that a wealth manager, wirehouse, or RIA might have? The end-to-end experience being completely low-touch is going to be a big factor.

The third factor, experience, is really around deep integration—who has the most connectivity with fund administrators, custodians, and tax providers so that with any change, you can almost act as the Zapier of the alternative investment universe. Clients don't have to change anything or communicate anything—you are managing all of the operational reconciliation on their behalf.

All of that packaged together, plus the first bucket in terms of the legal structure, is also going to involve who can give me the lowest fees—whether you're beating down fees of the fund admins and custodians or beating down your own fees by just making it really cheap to manage. Clients don't really care how—they just want lower fees overall.

Is there anything you'd add that we haven't covered?

One big trend and one big existential crisis that I saw coming up across all of the players within the alt space, whether that's GPs, wealth managers, fund administrators, custodians, or beyond: The reason why alts were so successful is because they were bespoke. Once you get really bespoke, it's hard to standardize data, standardize workflows, process reporting, and data language, which makes it hard to build technology that scales. These are things that are directly at odds with each other.

But even further, when you look at something like DLT where you come into the space and say, "If there's a great source of truth, a great standardized data language that can translate to anybody's custom database, connects via API, and generate documents," then you start to take away the power, the business, and the value proposition of fund administrators, tax preparers, and auditors. All of that logic can be codified by a central player.

While you can't change the way that the SEC requires books and records to be owned by a TA or a fund administrator, you can say, "I should be making it a lot faster and cheaper to do this business," or "KYC/AML can definitely be brought in-house and standardized by a third party that has automated third-party databases" and start to take that business away from fund administrators and TAs.

The way that this universe starts to change over time is you depend on these service providers in order to service your GPs and wealth managers. But by making that process smoother, faster, cheaper, and better, you pose an existential threat to these service providers. How do you strike that balance while still driving enough value that you can charge everyone for these additional services while reducing the total amount of fees that are charged across the universe?

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.