321. That is the number of API endpoints currently in FundCore. One endpoint stands for one action, whether it is creating an investor record, updating a capital account, calculating a distribution amount, running a net asset value report, validating wire instructions or flagging a compliance requirement. Some API endpoints perform simple tasks that can be completed in a fraction of a second. Others involve complex operations including multiple data validations, calculations and the application of business rules. When these API endpoints are built properly, they form the foundation that every fund administration platform requires.
The API endpoint count, for the uninitiated, is the number of separate actions that a software platform offers for programmatic access. In fund administration software, the endpoint count correlates with how broadly the platform can span a range of capabilities and edge cases. A fund administration software platform constructed with 30 endpoints may be suitable for routine investor accounting and basic reporting. A software platform with more than 300 endpoints, on the other hand, may be suitable for complex partnership provisions, multiple funds, international investors, cross-jurisdictional compliance obligations and all of the operational edge cases that arise when you actually model real-world fund agreements in software.
The vast majority of fund administration software vendors build for the 80 percent. That is, they build for the use cases that are most easily implemented, which typically involve funds that have simple fund structures, simple fund terms, domestic-only investors and a limited and simple set of operational edge cases. The resulting software works well for those funds, but falls apart when circumstances become the slightest bit complex. The software vendors know this. They assume that you, their customers, will work around the software’s limitations by using manual methods and spreadsheets. It’s how the software was designed. If the software doesn’t do something, it’s on you to fill in the blanks.
We set out to build FundCore based on a very different hypothesis: that fund administration software needs to be able to handle the full scope of the complexities of real-world funds, not just the narrower subset of use cases that are easier to model and implement in software. This necessitates a focus on edge cases early on in the product lifecycle, software code to account for variations in partnership provisions that other platforms don’t typically encode for and data architectures to represent fund operations that are, while common in our industry, often not well-documented by us. Today, the FundCore API has 321 endpoints, 1,060+ API test cases and handles the types of fund operations where other, generic platforms fail.
So What? Counting endpoints gives you a sense of how much of the operational burden falls on you versus what’s built in for you. It might feel like a capital call is just one endpoint: create capital call. In truth, that simple process includes dozens of steps, including: calculating each LP’s call amount based on the partnership agreement, confirming compliance to the terms, confirming whether the required notice period has passed, validating an LP’s wire instructions and current records with the fund, figuring out what (if any) tax withholding might be required for a particular LP based on their country of residence, drafting the notice document, recording it all in an audit report, and more. One naive way to implement this is as a single endpoint that assumes the fund will follow the standard rules of operation. If, however, the operating agreement doesn’t line up with those assumptions, then the API breaks or, worse, produces a misleading number. A comprehensive implementation decomposes this into distinct endpoints that calculate amounts, confirm compliance to partnership terms, verify wire instructions, assess tax implications, draft supporting documents, and log transactions, each capable of handling failures and edge cases properly. These APIs can then be called, sequentially, to complete the call. We looked at the API endpoint count of three competing fund administration platforms. Platform A has 47 endpoints, used for the standard operations (CRUD: create, read, update, and delete) of LP, fund, and transaction data. Platform B has 112, used for additional reporting, document management, and workflow automation capabilities. Platform C reaches a total of 287 endpoints, with additional reporting for compliance monitoring, multi-currency data, complex waterfall calculations, and tax reporting across borders. The upshot is that different fund administration platforms are built for different funds, and are priced accordingly. A serves funds that are fine with adding manual processes to supplement their software. C is for funds that want to run every bit of operations they possibly can on the software. With 321 total endpoints, FundCore exceeds even Platform C, in part, because we created fund administration capabilities for operational scenarios that other vendors overlook. We provide LP-side-letter-specific APIs, for example, to calculate custom waterfalls. We provide partial call APIs, where an LP wires in funds less than their full call amount. We have endpoints for recalculating historical distributions when an operating agreement for a fund was amended with retroactive effect. These aren’t edge cases in the sense that they are rare; rather, these are edge cases in that they are generally not handled by the other fund administration software that is on the market. A fund using other vendor software and facing one of these edge cases would have to take this into the back office and do the necessary math manually. The fund in question just needs to tell FundCore what is occurring to get this done on its behalf.
The Edge Cases That Caused Us To Write Endpoints We Never Intended To Write
There were some cases in the operational scenarios that drove us to write endpoints that we originally never wrote. The edge cases that we uncovered are real and that were uncovered while running our test scripts against actual operating agreements for funds and actual fund administration processes. In each instance of those edge cases, there was a discrepancy between the way that we thought funds were supposed to operate and the reality of the way funds operate under some partnership terms and across some sets of investors.
The first group of edge cases was related to classification of investors and variations in investor reporting rights. We started by designing an implementation in FundCore for an investor record that assumed all LPs were treated equally. We assumed that all LPs receive exactly the same information rights. But, real funds made it clear to us that LPs are not treated equally in every fund. Tax exempt LPs require different reporting than taxable LPs; international LPs have withholding tax requirements; ERISA LPs require monitoring of compliance; and some LPs receive rights to information in a side letter that is different from standard LP rights. We were therefore forced to implement an additional 17 endpoints that were driven by the need to handle these edge cases. The other edge cases we uncovered involved the timing and sequencing of capital events. We assumed, at first, that capital calls were executed in a clean, linear fashion: call capital; wires come in and the LPs’ cash contributions get recorded; and then, after a set deadline, the fund will close the call. But again, real funds do these things a little differently: sometimes a fund is calling for cash from investors, but an LP’s wire gets there late in the process after most of the other investors have wired in their cash; a single LP might wire the full call amount requested but might be sending more money than actually called; a fund might distribute capital from an invested asset and then decide to recapture all or some of that capital from an LP later; an LP might receive a call for capital for a deal that the fund ends up deciding to abandon. In order to handle these edge cases, we had to build some new endpoints into FundCore to ensure that we could manage the various states of the capital call and reversals. As an example, one growth equity fund called an $8.4M capital to be used for a single investment that had not been funded, and only $7.9M in capital had come in as of the deadline set in the notice of the capital call. This $7.9M would still go to fund the target of the call, and the investment would be made. But one of the LPs had requested an extension for two weeks to wire in the remaining $500K that this LP owed. As it would take longer for this LP to wire the remaining amount than to actually do the investment in the target asset, the fund needed to close out this partial capital call, while tracking the late wire for the reconciliation and to track the status of this investor in the future. Our original endpoints weren’t equipped to support partial closes. To accommodate this, we built three new endpoints to: (1) close a partial capital call, (2) monitor late contributions, and (3) reconcile them. These new endpoints are now used by multiple funds with similar timing challenges for capital calls.
There is also a third class of edge cases involving amendment to partnership terms, and retroactive calculation. We originally assumed that partnership terms were set in stone on the fund close, however, terms can be amended through the LP voting process and side letters. Furthermore, amendments can be made retroactively, so all distributions and management fee calculations in prior periods need to be recalculated. To support this feature, we built endpoints to process amendment to partnership terms, version terms with effective dates, and run the appropriate workflows to recalculate all relevant periods affected by a retroactive amendment. While not heavily used, this functionality is critical. For example, when a fund makes an amendment to the carry terms, they cannot only apply to the future. They must also recalculate all of their historical distributions to determine whether the GP received the proper distribution under the new terms.
Test cases to ensure edge case support
We have test cases for every endpoint to validate that the edge cases run as expected as well as validating that the endpoints run correctly for expected inputs. Our test suite contains over 1,060 test cases which validate the functionality for both expected inputs and edge case behaviors, including boundary conditions, error scenarios, and integration between endpoints. These test cases are all run on every change to ensure that any new functionality doesn't break existing functionality.
Our test cases list has grown organically over time. When we started building our capital call calculation endpoint, there were only 12 test cases (which covered simple cases with round commitments, simple percent based capital calls, and a variety of management fees). After testing 20+ different real-world partnership agreements, we added another 31 test cases to cover non-round commitments, various side letter amendments for LPs, handling partial contribution scenarios, and test cases to make sure the values can be expressed precisely to the penny because even a single dollar may cause a legal document to be rejected. Real world failures are among the best sources for test cases. After a beta user informed us that the distribution calculations were returning the wrong numbers for a fund with a European waterfall and clawback, we learned that the issue was the endpoint’s calculation of the cumulative preferred return across several distribution events. With the bug fixed, we created 8 more tests for those particular partnership terms that created the bug in the first place, and now this error can’t be repeated. Testing is especially critical when dealing with calculation endpoints that could have financial consequences. The waterfall distribution endpoints are composed of 147 test cases, designed to cover American and European waterfalls, preferred returns of different percentages, catch-up, tiers of carry, clawback, and LP-specific adjustments. The NAV calculation endpoints have 89 test cases to cover portfolio valuations, accruals, management fees, and reconciling cash balances. Each test case represents an opportunity for miscalculations to hurt investors or violate a regulation.
Architectural Choices That Enable 100% Test Coverage
As we developed the 321 working endpoints, we made some architectural choices along the way that put the ability to support edge cases and flexibility ahead of the need for speed. One of them was to build the platform on top of a domain model that represented the concepts that exist in fund administration directly, as opposed to the typical business entities that most software applications are built on. This domain features first-class objects for investors, capital accounts, partnership terms, waterfalls, portfolio companies, and capital events. The data and specific business logic for each of these objects are embedded directly into the objects themselves.
When an endpoint calls upon an object to create a capital call, it does so on a domain object such as CapitalCall, Investor, or PartnershipTerms. In that way, we ensure business rules are enforced. We don’t have to check in the endpoint that the capital call amount does not exceed the partnership terms or that it includes the correct investors; the domain objects perform those actions for us. The architecture makes every individual endpoint less complex but keeps business rules the same on every operation.
We made another choice to build a rules engine to determine partnership terms. Because partnership terms are written in natural language and describe a contract between two or more people, they are ultimately unenforceable by computers. We then take that language and translate it into computer instructions. As the fund gets built, we input all the partnership terms into FundCore. We set up everything from how to calculate the preferred return to which waterfall to use, the fees, the period of notice, and compliance triggers. Then, when the endpoints do the actual work, they check these rules. This separation of fund-specific terms from the more generic operations that a fund might have enables different operations to work with different terms consistently.
The last of our three big decisions was to log everything for our auditing system. Every time an endpoint creates, updates, or deletes data, we log what happened, when it happened, who did it, and why. This is our audit trail. It lets us be compliant. If you get an error, the audit trail helps debug it. We also have to show the LP and our auditor that. That is all of it. So every single time you are doing an operation, there is logging, and there is all that kind of stuff. You pay for latency, and it is worth it because it is important to know you are doing everything correctly. It is the whole point of fund administration: we have to show people how we did it and why it was right, and we can do that with this.
Everything in the system is a single thing, from the general ledger and the investor capital accounts to portfolio tracking and document management. We place a great emphasis on the connection of the data: it all connects to everything else. If you change a reference in one place, all the data that references that thing will update. Every endpoint has referential integrity. That is what allows us to have 321 different endpoints that all operate in sync with one another instead of having 321 completely independent operations. Otherwise, it would be a total pain to have to coordinate things on our own. It’s an automated process when we close a quarter. We do not have to reconcile everything all the time. If there is an issue, we only have to figure out what it is, as the system reconciles it for us. For more information on FundCore’s technical architecture, check out fund-core.com.
What Would I Do Differently Now?
There are a few things I'd do differently if I were building the same system today. I would have built out internationalization from the start. The second you build a new platform, you need to support international, non-USD-based investors from other countries. We had all of these fund companies come to us from abroad that had international, non-USD-based investors in their fund, and so we had to go back and add internationalization on top of everything that we had built. You'd want the core calculation engine to handle internationalization right from the beginning. We needed to deal with things like different currency conversions, different types of fees and tax requirements for different jurisdictions. We just didn't have any of that logic. So we had to redo all of it, which meant converting all the data as well. By building it out from the beginning, it would have been a global fund software company instead of a U.S. one, and I would have been able to get more funds that way. I also would have spent more time on API documentation and a good developer experience. This is one of those things where you have to build out the documentation for each endpoint as you go along. You can only do a single one or two at a time. If we had done that earlier, we could have been much more efficient with our API. Instead, we made sure that the end user wouldn't deal with us, but all of us dealing with the end user on the inside was a big pain. I also would have built out the LP portal much earlier. We were originally trying to build out a lot of the GP-focused things and features and built the portal for the LP at the end. It's much harder when you go at it backwards. If you build the portal for the investor first, it informs how you set up your data models and process the data. So you're getting a better user experience for the end user by building that at the beginning. Finally, I'd also add more automated testing. From the very beginning, we started adding automated testing as we ran across edge cases. So 18 months later, we're at 1,060 test cases. I'd probably spend more time on test-driven development, writing the tests first. The bugs would probably find us before we write the code. Writing the tests themselves was something we had already been doing, so the learning curve we went through to get here was quite pricey. Now it is baked in and part of the process.
The other lesson I would like to take away is that, if done right, fund administration is a much more complicated beast than many people assume. If a vendor says they have 30 endpoints, that either means you are running a very simple fund and can do without a ton of stuff, or else the end user is doing more manual work than they should be doing. There is no shortcut to coverage. Real funds have all kinds of nuances that require varying partnership terms and edge cases, all covered by dozens of endpoints, sometimes hundreds, at least. And that is why admins stick with spreadsheets: the software they have looked at has no way to cover their requirements in their fund admin business. They cover the hypothetical, not what a complicated limited partnership agreement would look like in operation. What about side letters? Nonstandard waterfall? Non-US fundraising? They must be thinking there is something easier they can do that would make sense for a real fund, and they would never be able to switch to a platform then.
That is why so many GPs are looking for software to automate their fund operations only to be left with something that doesn’t work because they are using the wrong software. FundCore was built to allow emerging fund managers to automate their operations completely from the start. You need to invest upfront properly encoding your partnership terms, training your team on how to use it, and going live with your funds on the platform. But that means you will be getting end-to-end automation, not just of 80% of your workflows.
You will have to choose between a tool that manages 80% of your operations and you need to find a workaround for 20% of them, or a software that covers over 95% of them. FundCore has 321 endpoints because those are the operations we need in order to do this right. We have 1,060 test cases because those are the ones that will cause simpler platforms to fail. FundCore’s architecture was built off years of experience in fund administration, built to manage your funds as if an administrator were running your business, not as a software engineer would conceive of operations.
Frequently Asked Questions
Why does fund administration software need hundreds of API endpoints?
Fund administration encompasses a range of workflows containing complex and varying edge cases. Fund administration software should have APIs for classification of investors, capital transactions with multiple edge cases, multiple variations of partnership terms, regulatory compliance and filings, multi-currency transactions, and reporting. Many fund administration providers only provide software for simple use cases, or they expect you to perform more manual work to handle edge cases outside of the software’s core offerings.
How many test cases should fund administration software have?
The number of test cases should be high enough to validate standard cases, boundary cases, error cases, and edge cases in each critical business case. FundCore has over 1,060 test cases in the areas of capital calls, distributions, NAV calculations, waterfall calculations, investor ledgers, and regulatory compliance. Fund administration is all about calculations. If an API is for financial reporting or calculations, then it requires significant test cases to ensure accuracy. Comprehensive test coverage provides you with higher confidence the platform will work for your funds.
What operational scenarios do most fund admin platforms fail to handle?
Most systems are not equipped to handle LP-specific side letter terms altering standard economics, partial commitments and late capital, capital recycling and retroactive partnership term, complex waterfall structures (carries at different levels, clawbacks), non-US investor tax withholding and reporting requirements, or portfolio companies with different currencies.
These scenarios occur regularly in real life and would require significant development time to implement in a systematic manner.
How long does it take to build a fund administration system?
To build comprehensive fund administration software requires 18-36 months of development time.
The software requires careful design of data structures, implementation of processes, calculation of NAV and waterfalls, generation of reports, investor portal functionality, handling of edge cases, and testing.
A system that claims to be built much faster is likely only handling a very small subset of features or has a very low scope.
Should emerging fund managers build their own fund administration software, or adopt an existing platform?
Most emerging fund managers should use an existing platform instead of building their own.
It takes a long time to develop fund admin software, and there will be ongoing maintenance and updates to support a custom solution. It costs $250K-$750K for basic functionality.
Platforms like FundCore provide comprehensive functionality for a fraction of the cost, on a monthly subscription basis.
It rarely makes sense to build your own software, since your fund probably does not have requirements that are not already met by an existing platform.