Compliance
April 2026
· TrackFundAI Editorial · 9 min read
SEBI's 2025 AIF amendments: what changed for Cat I, II and III managers
The amendments published in late 2025 read like a tidy-up exercise on the surface. The operational reality, when you start filing under the new framework, is more interesting.
The Securities and Exchange Board of India's amendments to the Alternative Investment Funds regulations are routinely covered as press-release summaries. A fund manager reads the bullet points, nods, and assumes their compliance team will figure out the rest. Then the next quarterly filing arrives and surprises emerge.
Three changes have material operational consequences this cycle:
1. Tighter capital deployment timelines
The expectation that committed capital be deployed within a defined window — and that idle capital sitting in the fund's account beyond that window be reported with reasons — is not new in spirit. What is new is the explicit reporting structure. Funds will need to track deployment maturity per scheme, per commitment, and surface it cleanly at filing time. The funds that will struggle here are the ones whose deployment data lives in three different spreadsheets that no one reconciles until the filing is due.
2. Beneficial-owner reporting at investor level
Investor-side beneficial ownership reporting is now expected at finer granularity. For LPs that are themselves investment vehicles — fund-of-funds, family-office SPVs, sovereign vehicles — this means tracking and refreshing the underlying ownership chain on a defined cadence, not just at onboarding.
The operational implication is straightforward: a one-time KYC capture is no longer enough. You need a workflow that revisits beneficial-owner data on a recurring basis, with audit-trail evidence of the refresh.
3. Side-letter disclosures
The amendments tighten the framework for what side-letter terms must be disclosed to other LPs and how. The interpretation is not entirely settled.
Most funds historically maintained side-letters as a separate, lightly-tracked corpus of documents. The new framework requires them to be machine-readable in your operational systems — because what was promised in side-letters now affects how distributions, capital calls and fee waivers must be computed.
What this means for the back-office
If your fund's operations run on spreadsheets, this cycle will hurt. The reporting precision now expected — across deployment, ownership and side-letter overrides — is not realistically achievable with manual reconciliation. The funds that handle this gracefully will be the ones with proper systems of record where each of these data points lives in one place, with one source of truth, and updates flow through automatically to filings.
The amendments are not a tax on funds. They are a forcing function for fund-tech adoption.
↑ Back to top
Industry
March 2026
· TrackFundAI Editorial · 6 min read
The state of alternative investment funds: where the capital flowed last year
A reading of the most recent industry data, with a focus on the structural — not cyclical — shifts.
The headline numbers in fund industry reports tend to obscure the more interesting story. Total commitments are up. Deployments are up. Cat II remains the largest category by AUM. Useful, but unsurprising.
Where Cat II credit is quietly winning
The story underneath the totals is the steady drift of allocator capital toward Cat II credit and real-asset strategies, away from blind-pool VC. The economics make sense — predictable yield, defined exits, lower J-curve — and the operational complexity is, frankly, lower for an LP committee to underwrite.
For managers, this has implications. A credit fund operates differently from a venture fund — different cadence of capital deployment, different reporting expectations, different waterfall mechanics. Many fund-management platforms built around the venture model do not handle credit cleanly.
The emerging-manager paradox
First-time managers raised meaningfully smaller average funds than the prior year, but the number of first funds raised held steady. The market is funding more managers with less capital each — which means each emerging manager has a thinner operational margin to work with.
The ones who will scale are the ones who treat back-office cost structure as a strategic decision from Fund I onwards.
GIFT-IFSC: from optional to default
The shift toward GIFT-IFSC for any fund with global LP exposure is now a market consensus. The mechanics are straightforward, the cost is reasonable, and it solves real structural problems for funds that want to raise from UAE family offices, Singapore HNIs and US institutional LPs in parallel.
Operationally this means more funds will run parallel onshore + IFSC vehicles. The ability to manage both from one workspace, with one set of books, is moving from nice-to-have to table-stakes.
↑ Back to top
Accounting
March 2026
· TrackFundAI Editorial · 12 min read
European vs American waterfall: a CA's guide to getting the carry math right
Hurdle, catch-up, clawback. The mechanics that look simple in a PPM and turn nightmarish in a spreadsheet.
Carry computation is one of the few areas in fund accounting where the documentation says one thing, the spreadsheet does another, and no one notices until the LP raises a question. This piece walks through the structural differences between the two dominant waterfall structures and the calculation traps that catch most internal models.
European waterfall (fund-as-a-whole)
The classic LP-friendly structure. The GP receives no carry until all LPs have received their full committed capital back, plus the preferred return. After that, the catch-up tier kicks in, then the carry split.
Sounds simple. The complexity emerges in two places:
- Timing of the preferred return calculation. Is it computed on contributed capital from the date of each capital call, or on aggregate committed capital? The PPM almost always specifies, but real-world calculations often drift toward whichever is simpler in Excel.
- Catch-up provision asymmetries. A 100% catch-up to a 20% carry percentage means the GP collects every rupee of distributions in the catch-up tier until they've caught up. Get one comma wrong in the formula and the GP is over-distributed by 8%.
American waterfall (deal-by-deal)
The GP-friendlier structure. Carry is computed deal by deal — each successful exit produces a carry distribution before the fund-level preferred return is satisfied.
The American structure shifts cash to the GP earlier, which is precisely why it has near-mandatory clawback and escrow mechanics on top.
The trap: tracking carry distributions per deal across multiple realisations, then running a fund-wide reconciliation at the end of life to determine whether the GP has been over-distributed. This is a multi-year tracking problem that most spreadsheets fail to model correctly.
The mechanics that get missed
Across both structures, three things consistently get computed wrongly:
- GP catch-up vs LP catch-up. Different structures and PPMs use the same word to mean different things. Read your PPM, not your template.
- Side-letter overrides. Fee discounts, carry waivers, hurdle adjustments — they need to flow into the waterfall computation, not sit as footnotes.
- FX-translation effects on USD-denominated commitments. Particularly relevant for GIFT-IFSC funds running parallel rupee and dollar vehicles. The translation policy at distribution time determines who is over- or under-paid.
The case for systematising this
Carry computation should not live in a spreadsheet. It is a core financial calculation with material consequences for both LP returns and GP economics, and the workflows are too complex and too high-stakes to live in formulas no one has audited.
Systems that model both waterfall structures parametrically — with hurdle, catch-up, carry-split, clawback and side-letter overrides as configurable inputs — produce the same answer every time, and produce an audit trail. Spreadsheets do neither.
↑ Back to top
Tech & AI
February 2026
· TrackFundAI Editorial · 7 min read
AI in fund management: where it adds real value, and where it's mostly theatre
A pragmatic framework for separating AI features that meaningfully change a fund's operations from features that make for good demos.
Every fund-tech vendor has, in the last 18 months, added "AI" to their feature list. Some of it is substantive. A lot of it is rebadged keyword search. This piece offers a working framework for telling them apart.
Real value · Tier 1: Anomaly detection
Anomaly detection across portfolio company KPIs — flagging when a portco's burn rate, revenue growth or unit economics deviate materially from the rolling baseline — is the AI use-case that funds use most heavily once it works. It compresses the time between an early warning signal in the data and the GP picking up the phone to the founder.
The catch: it requires clean, structured portfolio data. Funds whose portfolio reporting lives in PDF investor updates will not benefit. Funds that ingest structured KPIs monthly will see immediate value.
Real value · Tier 2: Regulatory parsing
Parsing a regulator's circular and surfacing the operational implications for your fund's specific structure is genuinely valuable AI work. The volume of circulars across SEBI, IFSCA, RBI, MCA and FIU-IND is too high for any one compliance team to keep up with manually. Done well, AI saves hours of triage per week.
Real value · Tier 3: Narrative generation
Drafting LP letters and NAV commentary from underlying numerical data — the first draft, not the final — is a meaningful productivity gain. Not because the AI writes well; it doesn't, especially. But because a structured first draft is dramatically faster to edit than a blank page.
Theatre · Most "AI chatbots"
A chatbot that lets you "ask questions about your fund data" sounds compelling and is almost always less useful than the underlying dashboard. Natural language is a lossy interface for tabular data. Real fund managers want filters, not conversations.
Theatre · "Predictive risk scoring" without disclosed methodology
If a vendor claims to predict portfolio risk and won't tell you what features the model is using, what time horizon it forecasts, and how it has performed historically, the model is decoration.
Predictive models in fund management are useful. Predictive models in fund management without methodology disclosure are a liability — both because they may be wrong and because regulators may eventually want to inspect the basis of any AI-driven decision in a regulated workflow.
↑ Back to top
Compliance
February 2026
· TrackFundAI Editorial · 11 min read
Setting up a GIFT-IFSC fund: the IFSCA framework, in operational detail
A working manual for the GIFT-IFSC route — registration, vehicle structure, capital calls, NAV reporting and the recurring filings that follow.
GIFT-IFSC has moved from a niche option to a default consideration for any fund with global LP exposure. The IFSCA framework is well-documented but distributed across multiple circulars and FAQ documents. This piece consolidates the operational reality.
Why GIFT-IFSC, structurally
The IFSC framework allows funds to operate under a regulatory regime that is closer to global fund-management norms while remaining within India's jurisdiction. The practical benefits — USD denomination, exemptions on certain capital flows, eligibility to receive direct foreign LP commitments — are well known. What is less appreciated is how much operational simplification this creates for funds with mixed-currency LP bases.
Structure: the parallel-vehicle pattern
The most common operational structure for funds raising both domestic and international capital is a parallel-vehicle setup: an onshore Indian AIF and a GIFT-IFSC vehicle, investing pari-passu into the same underlying portfolio companies. This requires careful operational discipline — the two vehicles must invest at the same prices, same rounds, same instruments, and the carry economics must reconcile across both.
Capital calls in two currencies
Capital calls in a parallel structure are issued simultaneously to both vehicles, denominated in INR and USD respectively, with the deployment ratio fixed at scheme launch. The operational challenge is FX translation at deployment time — the two vehicles will not contribute exactly proportional rupee amounts to each investment because the FX rate moves between call and deployment.
NAV reporting
IFSCA-aligned NAV reporting expects USD-denominated NAV per unit, which means dual-NAV computation: the fund's underlying portfolio is held in INR but reported in USD. The translation methodology — period-end FX, weighted average, or specific-cost — needs to be consistent and documented.
The recurring filings
The cadence of IFSCA filings is broadly comparable to SEBI's AIF filings — quarterly returns, annual returns — but the formats and emphases differ. Funds running parallel vehicles need to maintain two separate filing calendars and two separate sets of returns, even when the underlying economics are pari-passu.
Where this gets operationally hard
The complexity is not in any single workflow. It is in maintaining consistency across two parallel sets of books, two regulatory filing cadences, two currency denominations, and one underlying portfolio. Spreadsheet-driven operations break under this load. Even reasonably modern accounting tools struggle. The funds that handle this well are the ones with operational systems built to model parallel vehicles natively.
↑ Back to top
LP Relations
January 2026
· TrackFundAI Editorial · 8 min read
What LPs want in their quarterly reports (it isn't more pages)
A consolidated read of what allocators have told us, in conversations across India, the UAE and Singapore, about the reports they reach for first.
Most quarterly LP reports are written by the fund team imagining what an LP wants to see. Most LPs read those reports imagining the fund team has imagined wrongly. Both groups are usually right.
What LPs use quarterly reports for
Reports do not drive re-up decisions. Conversations do. Reports are the substrate that those conversations stand on. An LP committee member reading a quarterly report is doing one of two things: building a working memory of where the fund is, or checking that nothing has gone unexpectedly wrong. Almost never are they reading for joy.
The seven data points that matter
- Capital deployment rate. Of committed capital, how much is deployed, in what, and at what pace versus the original strategy.
- Realised vs unrealised returns. The split. Funds that quote IRR without distinguishing this lose credibility.
- Concentration risk. Top three positions as a percentage of NAV. If it's over a third, explain.
- Mark-up methodology changes. If a position was marked up this quarter, on what basis. New round? Comparable transaction? Internal model?
- Fee transparency. Management fee, fund expenses, deal costs, all stated, all reconcilable.
- Strategy commentary that's about strategy. Not "the macro environment was challenging".
- Forward calendar. Expected capital calls. Expected exits. Expected reporting cadence.
The ten that don't
Macro commentary on geopolitics. Photographs of portfolio company offices. Generic ESG paragraphs. The CIO's reading list. Detailed operational metrics on portcos the LP has never met. Page after page of "team activity". Long-form fundraising commentary. Decorative org charts. Awards. Logos.
The most respected funds we know send shorter reports. The least confident send longer ones.
The format that wins
One page of dashboard. One page of strategy commentary. One page of forward calendar. Detailed appendices for the LPs who want them, but not as the headline. The LP who wants more detail can pull it from the LP portal — which is increasingly how serious allocators want to consume their data anyway.
↑ Back to top
Accounting
January 2026
· TrackFundAI Editorial · 10 min read
The seven NAV calculation pitfalls that show up in every audit
Stale FX rates, mishandled equalisation interest, side-pockets bleeding back into main NAV. The errors that recur across funds — and the workflow logic that prevents them.
If you've audited fund books for any length of time, you stop being surprised by the same errors recurring. Different funds, different teams, the same handful of mistakes. Listing them here is partly catharsis and partly a checklist.
1. Stale FX rates on USD-denominated holdings
The fund holds a position in a USD-denominated instrument. The NAV is computed monthly. Somewhere between months two and three, the FX rate used to translate that holding stops being refreshed. By month six, the position is being marked at a six-month-old rate. This is not a hypothetical — it shows up in maybe one in five audits.
2. Equalisation interest on subsequent closings
When a fund admits an LP at a subsequent closing, the late-comer needs to compensate the earlier LPs for the time-value of the capital they had already deployed. The mechanics — what rate, on what notional, for what period — are well-defined. The execution is consistently wrong, particularly when the fund has had multiple closings.
3. Side-pocketed assets re-entering main NAV
An illiquid position is side-pocketed — moved out of the main NAV, accounted for separately. Months later, the position is partially realised. The realisation finds its way back into the main NAV and inflates it, even though the original side-pocket should have been treated as a separate accounting entity. Common, easy to fix structurally, hard to fix retrospectively.
4. Management fee accruals diverging from cash flows
The fund accrues management fees daily. The fund pays management fees quarterly. The cumulative accrual and the cumulative paid amount drift over time, often by amounts that look like rounding error and aren't.
5. Capital call timing misalignment
An LP funds a capital call after the period close but before the NAV is struck. Was the capital received in this period or the next? The accounting policy should specify; in practice, it varies fund-to-fund and sometimes call-to-call within a single fund.
6. Carried-interest accruals as a deduction from NAV
Some funds accrue carry as a liability against NAV (reducing reported NAV), some don't. Both are defensible, but not disclosing the policy and not being consistent across periods causes audit findings.
7. Distribution-in-kind valuation
Distributing securities to LPs at the closing price on the date of distribution is the standard. Funds occasionally distribute at a board-approved fair value that doesn't reconcile to a market price, with no documentation of why. The auditor will, eventually, find it.
The structural fix
Each of these errors arises because NAV computation lives in spreadsheets where the policy is implicit and the calculation is manual. A NAV engine that encodes the policy explicitly, runs the same calculation every period, and surfaces exceptions for review eliminates the entire class of errors. The cost of building this is high. The cost of not having it is paid in audit findings, restatements, and eventually LP credibility.
↑ Back to top
Tech & AI
December 2025
· TrackFundAI Editorial · 9 min read
Why fund-tech needs database-layer multi-tenancy (and why most platforms get this wrong)
Application-layer isolation is not isolation. Why the choice of how multi-tenancy is implemented is the most consequential security decision in fund-tech.
Multi-tenancy means many customers sharing one application infrastructure. The choice that follows — at what layer the customers' data is isolated from each other — determines how secure the platform really is.
Application-layer isolation
The simplest pattern. All customers' data lives in one database, in one set of tables, with a tenant_id column. Every query in the application code includes a "where tenant_id = X" filter. As long as every query is correctly written, customers' data stays isolated.
The problem: a single missing filter — in a query, in a report, in an export, in an analytics job — and one customer's data appears in another customer's view. This is not a hypothetical risk; it is the most common security incident class for SaaS platforms.
Database-layer isolation
The pattern we use. Tenant isolation is enforced by the database itself, via row-level security policies that the application cannot bypass. Even if a developer writes a query that forgets the tenant filter, the database refuses to return rows that don't belong to the connecting tenant.
Application-layer isolation says "trust the developer to filter every query correctly". Database-layer isolation says "the database itself will not return data the connecting user is not entitled to".
Why this matters more in fund-tech
In most SaaS, a multi-tenancy bug is embarrassing. In fund-tech, a multi-tenancy bug is a regulatory incident. If one fund's LP commitment data, NAV computation or compliance filings appear in another fund's interface, that is a confidentiality breach with disclosure obligations.
The cost of building database-layer isolation is meaningfully higher than application-layer isolation. The argument for it is that the worst-case incident cost is asymmetric — a class of incident that simply cannot happen.
How to evaluate this in a vendor
Three questions to ask any fund-tech vendor:
- At which layer is tenant data isolated?
- What database technology is used, and does it support row-level security policies?
- If a developer writes a query that forgets the tenant filter, what happens?
If you cannot get clear answers to all three, the vendor's security model is not yet mature enough for a regulated workflow.
↑ Back to top
Industry
December 2025
· TrackFundAI Editorial · 7 min read
The emerging-manager playbook: scaling from Fund I to Fund III without losing your back-office
A practical sequencing of operational decisions for first-time managers. What to outsource, what to build internally, when to bring fund admin in-house, and the tech stack that scales.
The strategic decisions of an emerging manager get the attention — what's the thesis, who are the LPs, what's the differentiation. The operational decisions get the consequences. Most emerging managers underinvest in operations until something breaks; the ones that scale make a small set of correct operational choices early.
Fund I: deliberately under-built
Outsource almost everything. Fund admin to a third party. Compliance to consultants. NAV and accounting on a basic platform. The reason is not cost — it's focus. Fund I is about deploying capital and building track record, and any operational hour spent on internal infrastructure is an hour not spent on portfolio.
The single internal investment worth making: a system of record for LP commitments, capital calls and distributions. Not a spreadsheet. Even if everything else is outsourced, you need internal source-of-truth data for these flows.
Fund II: bring select functions in-house
By Fund II, you have learned which operational functions matter most to your LP relationships and which don't. The pattern we see: LP-facing functions move in-house first. Capital call notices, distribution statements, LP portal — these are the touchpoints where you cannot afford a third-party's response time or quality.
Fund accounting and NAV usually stay outsourced through Fund II. The marginal benefit of internalising them is small relative to the operational complexity of running an in-house accounting team.
Fund III: the platform decision
By Fund III, you are running parallel funds with overlapping LPs, and the marginal cost of every additional fund-tech license, fund-admin engagement and consulting hour starts to compound. This is the point at which most managers consolidate onto an integrated platform. The decision criterion: can the platform handle parallel funds with shared LPs without re-keying data.
The tech stack that scales without rebuilds
The mistake that costs the most time at Fund III is having to migrate off systems chosen at Fund I. The systems that scale are the ones that:
- Support multi-fund, multi-scheme operations from day one — not as a future enhancement.
- Handle parallel onshore and IFSC vehicles natively.
- Generate regulatory filings in the regulator's exact format.
- Provide LP-facing portal capability that you can white-label.
None of these are difficult to test for at vendor selection. The mistake is testing for them only when they're needed, which is always too late.
↑ Back to top