In the U.S., ETF share classes are the product story of the year in fund management. The SEC’s 2025 decision on share class relief gave the green light, and since then the first funds have launched with plenty more following behind. Released last year, the Investment Company Institute’s whitepaper on ETFs discusses the regulatory, tax and operational considerations, with product strategy taking a central place in industry discussions:
- Which funds get an ETF class?
- How does distribution change?
- What does all this mean for investor access?
All crucial questions, but equally important: is your investops infrastructure built to handle two completely different order types on a single system of record?
The Product Decision Is Only Part of the Conversation
Upon choosing to launch an ETF share class, the immediate focus is typically on distribution, tax efficiency and competitive positioning.
But what happens when a traditional mutual fund and its new ETF share class share one single portfolio while running on two totally different order models? After all:
- The mutual fund class: Takes cash in and out.
- The ETF class: Takes in-kind creations and redemptions through Authorized Participants (APs), requiring portfolio composition files (PCFs) and basket calculations.
To account for both, you need a platform that can accommodate multiple structures.
One Portfolio, Two Order Models
Most fund setups add new products next to existing funds. An ETF share class adds the complexity inside the fund itself. Both cash orders and stock trades are hitting the exact same portfolio, the same tax records and the same books at the exact same time.
Keeping these numbers lined up is a high-stakes daily requirement:
- Income and expenses: Must be split accurately across classes with different fee structures, constantly, because people are trading the ETF class throughout the day.
- Payouts: Will work differently for each share class.
- The daily NAV, the ETF creation basket and the portfolio list: These all describe the same pot of assets, but they go out to different groups on different schedules. If a late trade or price fix comes in, it has to update everywhere all at once.
- Regulators: Will want to see the structure as a single fund, so your controls have to cover everything.
On a platform built for flexibility, like FundGuard, that alignment is a natural state. The classes are lenses on one set of records, the basket data derives from the same accounting state as the NAV and a correction lands once, everywhere. On an operating model where mutual fund workflows, ETF processing and basket calculation live in separate environments, the same structure means keeping several systems in step around a single portfolio, daily, with reconciliation carrying the load.
When you try to force this using separate systems, with one for mutual funds, one for ETFs and another for baskets, you end up spending valuable time trying to keep tools from falling out of sync with one another. It can work, but it costs more, carries significantly more risk and doesn’t support your scaling ambitions.
Stop Rebuilding Your Tech for Every New Fund Structure
If you’re finding yourself constantly in the middle of this conversation, with every new product launch, it’s time to step back and look at the pattern. Active ETFs, semi-liquid vehicles, evergreen funds and tokenized assets, every new structure breaks the boundaries old investment accounting platforms were built around.
The traditional fix has always been layering on more software: buy a specialist tool, build an integration and hire people to reconcile the differences. Do that for twenty years and your operations team ends up running five separate environments just to get through a daily valuation.
This is why architecture matters more than any single product. When a new fund type arrives, your tech stack handles it in one of two ways, either:
- It’s a setting: Your current investment accounting platform already understands the workflow. You flip a switch and configure it. Or,
- It’s a project: You buy a new system, build new pipelines and spend nine months on delivery.
If you’ve got a tech stack built for today, then you get to focus on strategy and commercial growth, while firms with the second tech stack are stuck treating every single product launch as an expensive IT overhaul.
What Configuration Looks Like for an ETF Share Class
On FundGuard, ETF capability is enabled at the share class level. One class of a fund takes cash subscriptions and redemptions while another takes creations and in-kinds, both against the same portfolio within one system of record. Basket calculation, historically run in separate applications outside the accounting environment, happens inside the engine, from the same data that produces the NAV. Lot relief methods can differ by transaction type within one fund, which is what the tax mechanics of the ETF wrapper depend on. And because multi-book architecture derives class-level and fund-level views from the same events, the two workflows agree.
When it comes to oversight, NAV validation, exception handling and controls run against the one accounting state the classes share, so adding an in-kind class extends existing oversight instead of spawning a parallel control environment that has to be reconciled to the first.
Managers Launch Structures, Servicers Multiply Them
For an asset manager, an ETF share class is one decision about its own product range, and the architecture question is about how much each launch costs in time, money and operational surface area.
But a fund administrator does not choose which structures arrive. Its clients choose, and each mandate lands whatever mix of mutual funds, ETF classes, semi-liquid vehicles and private structures the client’s strategy produced. A servicer running a separate environment per product type repays the fragmentation cost with each new client, and the operating model scales by adding people to reconciliation. A servicer running one engine with native support per structure onboards the mix as configuration, and the margin difference between those two positions grows with the book of business. The firms with the least control over which structures they support have the most riding on architecture that absorbs them.
Asset owners feel a smaller version of the same thing through their managers and administrators, because the cost and error rate of fragmented operating models eventually surface in fees, in reporting lag and in the confidence they can place in a consolidated view.
How to Tell If Your Platform Is Modern
For firms weighing platforms ahead of a share class launch, feature checklists answer less than they appear to, because most vendors can claim ETF support in some form. The revealing question is about the next structure, whatever it turns out to be: when a product arrives that this platform was not specifically built for, what happens?
One unified engine answers instantly: flip the switch, configure the workflow and go live. But multiple platforms put together through acquisition will usually require a long, expensive statement of work.
Choices and Commitments
Product roadmaps are flexible and can be rewritten every year based on market trends.
Your legacy investment accounting platform is not. After all, it’s often a multi-year commitment.
ETF share classes are exposing this right now, but they won’t be the last product structure to do so. You should be able to respond and launch new products and assets to drive revenue, whether that’s ETF classes, evergreen funds or tokenized assets, without your platform getting in the way.
That freedom only exists when your infrastructure treats new structures as simple settings, not massive engineering projects. The architecture choice you make today will dictate how fast your business can move for the next decade.
Book a FundGuard Demo
If ETF share classes and future structures are on your roadmap, the fastest way to test a platform is to see it. Request a demo and we will show you a fund running cash and in-kind classes on one engine.
Frequently Asked Questions
Why does operational architecture hold as much weight as product structure for ETF share classes?
Product structures are strategic choices firms make frequently and quickly with proper due diligence. The underlying operational infrastructure changes rarely and decides whether each new structure is a configuration or a multi-quarter project. A mutual fund and its ETF share class share one portfolio across two order models, so the viability of the structure depends on the platform keeping both workflows continuously aligned.
What makes an ETF share class operationally demanding?
One portfolio serves two order models at once. The mutual fund classes take cash subscriptions and redemptions while the ETF class takes in-kind creations and redemptions through Authorized Participants, with basket calculation, portfolio composition files and per-class accounting all drawing on the same holdings, tax lots and books.
What does it mean for a product structure to be a configuration instead of a project?
Configuration means the investment accounting platform already understands your structure’s workflow natively, so it can be enabled within the existing platform. A project means acquiring or building additional systems, integrating them and reconciling between them. The first saves a huge amount of cost and time on each product launch.
How does FundGuard support ETF share classes?
ETF capability is enabled at the share class level, so cash and in-kind classes operate against the same portfolio within one system of record. Basket calculation runs inside the platform from the same data that produces the NAV, lot relief methods can differ by transaction type within one fund and multi-book investment accounting architecture derives class-level and fund-level views from the same events.
What should firms ask platform vendors before a share class launch?
Beyond ETF feature support, ask what happens when a structure the platform was not specifically built for arrives. The answer you’re looking for is configuration, while a statement of work would be a red flag.
Will ETF share classes be the last structural change fund operating models face?
The answer is likely no. Active ETFs, semi-liquid vehicles and evergreen structures each arrived within recent memory and tokenized share classes are emerging now. Portfolio convergence keeps producing products that cross the boundaries older operating models were organized around, which is why architecture that absorbs new structures matters beyond any single launch.
