The hidden cost of building your own fund data management platform
- Jul 10
- 8 min read
Updated: Jul 14
Written by: Jonathan McKie
For many smaller and mid-sized fund management businesses, the appeal of building internal tools is easy to understand. In our experience working with fund managers, the decision often starts pragmatically: add a small internal team, use Excel where it works, shape outputs around the business, and avoid a larger external commitment.
The problem is that this can make the decision feel narrower than it is. It isn’t just a platform licence versus one or two salaries. It is also about who maintains the logic, what happens when key people leave, and how easily the firm can scale its data processes over time.
Internal teams are often making reasonable decisions with the information available. The issue is that the question itself is usually framed too narrowly. It means many firms are still evaluating the question as a headcount decision when it is really an operating model decision.
The real issue is operating model risk
Internal teams can produce useful reports, automate files and reshape administrator data. The concern is rarely whether those people are capable. It’s that, over time, the firm’s data backbone can become dependent on a small group’s design choices, documentation, security practices, edge-case handling and availability.
Very often, this asks analytically-minded people to take on data architecture and system design responsibilities that sit close to their roles, but are not the same discipline. That can work for a while, but business knowledge still needs the support of engineering discipline, security practice and long-term maintainability.
When knowledge is concentrated in one or two people, resilience falls. If they leave, change roles or become unavailable, the business may have to reverse-engineer its own reporting logic, spreadsheet conventions, file mappings and scripts before it can move forward. That is where build-it-yourself initiatives become expensive: not only in build costs, but also in maintenance, rework, documentation, replacement, governance and delays.
Excel is useful, but it is not a platform
Excel remains an excellent tool for analysis, interrogation and business consumption. The challenge starts when Excel-based fund reporting gradually evolves from an analysis tool into a database, rules engine and reporting platform all at once, often without anyone setting out to design it that way.
This is not a theoretical concern. One review of spreadsheet quality research found that around 94% of audited spreadsheets contained at least one fault, reinforcing the case for managing spreadsheet quality across the full life cycle rather than assuming correctness.
For a fund manager, Excel should sit on top of governed data. It shouldn’t be the central system of record. A durable data platform needs audit trails, controlled overrides, repeatable ingestion, role-based access and reliable downstream reporting.
Custom tools accumulate debt
Internal tools often start with practical fixes: clean a feed, automate a report, reshape a holdings file or speed up a performance process. Each shortcut may seem reasonable. Over time, however, those shortcuts can harden into a brittle operating environment.
In fund data, weak architecture spreads quickly because pricing logic, returns, AUM, instruments, benchmarks, factsheets, portals and reporting are connected. A decision made in year one can still affect every reporting cycle in year three.
A fund data management platform is more than software
The value of a purpose-built fund data management platform is not only the code. It is the team, method and production experience around it.
The client is not simply licensing a tool. They are buying into a production-tested platform supported by implementation and advisory expertise. That includes help with warehouse loads, reporting, workflows, operational processes, extracts and practical adoption in the manager’s actual environment.
This is why comparing a purpose-built platform to a single salary line is misleading. The platform includes capability, implementation depth and advisory capacity that a small internal team would otherwise have to build over time.
Fund managers should focus on fund management
Most fund managers want their teams focused on investing, client service, reporting obligations, risk management and responsible asset growth. But over time, a surprising amount of internal capacity can end up absorbed by ingestion pipelines, warehouse design, data lineage conflicts and fragile reporting backbones.
Internal teams still have an important role. Analysts, operations teams and portfolio managers create the most value when they can work on top of trusted, structured and audited data, rather than trying to create the underlying platform themselves.
AI does not remove the risk
AI can help small teams write code faster. But shipping trusted, governed software still takes architecture, testing, security, adoption, maintenance discipline and shared ownership.
The risk is that AI can make it easier to defer platform decisions while the business accumulates more scripts, spreadsheets, hidden logic and technical debt. The question isn’t whether AI can help write code. It can. The question is whether core data processes should depend on tools and scripts that may not yet have the controls, review discipline and shared ownership of a proper platform team.
A better use of AI is often downstream: connect it to a governed database, then let portfolio managers and analysts use it to interrogate trusted data, test ideas, explain movements and improve reporting. In that model, AI supports investment and analytical work instead of asking the business to become its own software platform team.
When internal build makes sense
Internal development isn’t always wrong, but weighing internal build against a purpose-built fund data platform means being honest about where the firm’s real capability sits. It can make sense when the firm is extending a strong existing platform, reducing system sprawl, creating differentiated commercial IP, meeting requirements that the market genuinely cannot support, and doing so with deep internal capability in architecture, governance, maintenance, integration and documentation.
It is usually harder to justify when a small, isolated team is expected to build the core operational backbone from scratch while also supporting day-to-day business needs.
The strongest model is often to buy the backbone and build selectively at the edges. A stable data platform can provide the warehouse, ingestion capability, auditability, controlled overrides and reliable access. The business can then add reports, workflows, bolt-ons and extensions where genuine business-specific value exists.
What fund management firms actually need
The pattern across these points is consistent: fund managers want their data work to be routine. Ingestion must run reliably, changes must be traceable, reports must use a trusted golden copy, and master data management must provide a single controlled view of funds, instruments, prices, returns, and AUM.
This is not aspirational; it is an operating standard. The question is whether the firm creates this standard from scratch or adopts an existing one.
A suitable data management platform should simplify and secure repeatable data work. This means reliable ingestion, a central hub for core fund data, clear audit trails, sensible controls for changes, and easy access for those who need data in Excel, reports, dashboards, or portals.
The less visible cost is delay
The obvious cost of a platform is the fee. The less visible costs of not buying one are key-person dependency, weak documentation, inconsistent architecture, technical debt, fragile spreadsheets, security exposure, replacement risk and slower operational maturity.
Adopting a governed platform doesn't limit flexibility; it provides a foundation for it. It is the next stage of operational maturity. For a growing fund manager, it is usually the more commercial long-term choice.
A purpose-built alternative: fund data automation with Ocellics FundSolve
This is the gap Ocellics FundSolve was built to close. Ocellics FundSolve is a production-tested fund data platform supported by implementation and advisory expertise. It provides a stable warehouse, ingestion capability, auditability, controlled overrides, and reliable access, helping fund managers avoid building and maintaining the operational backbone themselves.
FundSolve supports automatic loading of ASISA files, Eagle files and other administrator data, including multiple administrators and configurable checkpoints for missing files. It centralises funds, instruments, prices, returns, AUM and attributes, while retaining originals and allowing controlled overrides. Teams can access raw and aggregated data in Excel, custom reports, dashboards, role-based access and portal interfaces where appropriate.
Ocellics also offers a managed Azure environment and an advisory-led MVP approach. Engagements can start with core data flows and Excel outputs, then expand fund types, reports and workflows in a controlled cadence.
References
Light, B. & Sawyer, S. (2007), Locating packaged software in information systems research, European Journal of Information Systems. Supports the argument that packaged software is developed by specialist groups and can reduce maintenance burden and deployment effort. link.springer.com
Sawyer, S. (2000), Packaged software: implications of the differences from custom approaches to software development, European Journal of Information Systems. Supports the packaged-software argument and explains the differences between specialist products and custom internal development. link.springer.com
Robillard, M. P. (2021), Turnover-Induced Knowledge Loss in Practice, ESEC/FSE. Supports the point that when developers leave, knowledge loss affects productivity and code quality. cs.mcgill.ca
Jabrayilzade et al. (2022), Bus Factor in Practice, ICSE-SEIP, and Ferreira et al. (2019), Algorithms for estimating truck factors: a comparative study, Software Quality Journal. Supports the key-person risk, bus factor and source-code knowledge concentration arguments. arxiv.org; link.springer.com
Etemadi, Bushehrian & Robles (2022), Task assignment to counter the effect of developer turnover in software maintenance: A knowledge diffusion model, Information and Software Technology. Supports the link between turnover, knowledge retention and maintenance cost. sciencedirect.com
Poon et al. (2024), Spreadsheet quality assurance: a literature review, Frontiers of Computer Science. Supports the point that spreadsheet-heavy operating models are risky in decision-support contexts. link.springer.com
Avgeriou et al. (2024), Technical Debt Management: The Road Ahead for Successful Software Delivery. Supports the technical debt and long-term maintainability argument. ieeexplore.ieee.org
Maruping, Zhang & Venkatesh (2009), Role of collective ownership and coding standards in coordinating expertise in software project teams, European Journal of Information Systems. Supports the point that team-based ownership and standards improve technical quality. researchgate.net
Negri-Ribalta et al. (2024), A systematic literature review on the impact of AI models on the security of code generation, Frontiers in Big Data; Wang et al. (2024), Is Your AI-Generated Code Really Safe? Evaluating Large Language Models on Secure Code Generation with CodeSecEval; and Booth et al. (2024), Secure Software Development Practices for Generative AI and Dual-Use Foundation Models. Supports the article’s caution that AI-generated code still carries security and governance risk. frontiersin.org; arxiv.org; nist.gov
Multi-company AI coding tools study (2025), IBM enterprise AI coding tools case study (2024), BIS (2024), AI and productivity: evidence from a field experiment, and NBER working paper (2026). Support the point that AI productivity gains vary and do not automatically translate into shipped, adopted software. ssrn.com; arxiv.org; bis.org; nber.org
Lindohf et al. (2021), Evaluation of software product line engineering, and Software product line engineering in Scrum (2023). Support the point that reuse, reference architectures and modular core assets can reduce time to market and maintenance costs, but require deliberate investment. link.springer.com; mdpi.com
Aleatrati Khosroshahi et al. (2016), Causes and Consequences of Application Portfolio Complexity – An Exploratory Study; Fuad et al. (2024); Liao et al. (2023); and Ma et al. (2021). Supports the points about application portfolio complexity, integration capability, absorptive capacity and the need for complementary organisational capability. link.springer.com; tandfonline.com; frontiersin.org; researchgate.com
Shah et al. (2025), Navigating the productization landscape: a systematic literature review approach. Supports the point that organisations can create value by standardising repeatable capabilities and turning expertise into marketable offerings. researchgate.com
Research on packaged enterprise systems customisation (2023) and Obtaining value from the customisation of packaged business software. Supports the point that customisation decisions need to weigh development, maintenance, integration and performance trade-offs. tandfonline.com; researchgate.com
BCG (2025), Buy-and-build strategy unlocks greater ops and tech value, and Baytech Consulting (2025), Rethinking build versus buy. Practitioner support for buying the backbone and building selectively around it. bcg.com; baytechconsulting.com
