Selection Guide
How to Choose Family Office Software
What decides the outcome of a family office software selection is not the length of the feature list — it is eight things: how many custodians the vendor connects to directly, and who is responsible for the data it cannot reach; whether structured products and private assets are genuinely modelled inside the system or patched together in Excel outside it; whether multi-entity ownership structures can be modelled and consolidated with automatic look-through; whether the system forecasts future passive events rather than only reporting history; whether you can change report definitions yourself; who maintains the data day to day and how that is priced; where the data is stored and against which compliance frameworks; and whether pricing scales with AUM and whether you can take your structured data with you when you leave. The recommended sequence is to write your requirements using your own real holdings and your own real report templates first, then look at demos — family offices that watch demos first almost always end up with a requirement list assembled from vendors' strengths. The three things most often underestimated in implementation are migration effort, post-launch reconciliation rework, and the ongoing headcount cost of data operations.
Define Requirements Before You Look at Vendors
The most common sequencing mistake is booking three or four demos and then reverse-engineering requirements from what was shown. A demo exists to showcase what a vendor does best, and every vendor is best at something different. The result of a demo tour is usually a requirement list stitched together from several vendors' strengths that no single vendor can satisfy.
A more effective sequence is to spend one or two weeks writing your own requirements, then take that list to each vendor. It does not need to be a formal RFP document, but it should cover four things:
One: an asset inventory. List every asset class the family currently holds, noting where each is custodied, how it is recorded today, and where the data comes from. This inventory determines how you will test the data ingestion and asset coverage criteria in section 3.
Two: a report inventory. Collect every report currently in use — for family members, for the investment committee, for tax advisers. These reports are exactly what the system will have to produce after launch, and they are the most realistic material for testing a vendor's customization claims.
Three: an operations walkthrough. Write down the fixed monthly actions: who receives statements, who enters data, who reconciles, who produces reports, and how long each takes. The value of the system ultimately shows up as compression of these actions, not as the number of charts on a dashboard.
Four: people and budget boundaries. Be explicit about how much internal capacity you can commit to implementation and ongoing maintenance, and about the budget range. Both will eliminate some options immediately, and the earlier they are clear the less time is wasted.
With these four inputs, the questions in the next section become specific, and vendors' answers become verifiable.
Eight Evaluation Criteria
The eight criteria below are ordered by how frequently they become points of contention in actual selections. Each gives questions you can put directly to a vendor, plus why the criterion affects long-run operating cost.
Data Ingestion Breadth
Ask your vendor
- Which custodians do you connect to directly today? Please name them, and specify which data types each connection covers (positions, transactions, cash flows, valuations)
- For institutions the direct connections do not cover — do we enter the data, or do you parse it?
- If AI parsing is involved, can you run a batch of our own historical statements first so we can see the accuracy rate and the types of errors?
- How long does adding a new institution take, and is it charged separately?
Why it matters
Family office assets are typically spread across several private banks, brokers and fund platforms, of which only a subset provides a standard data interface. The rest arrive as PDF statements, email notifications, sometimes paper. What determines long-run operating cost is not how many direct connections exist, but how the remainder is handled. If the answer is that the family office enters the data, then monthly manual entry becomes a permanent fixed cost, and entry errors propagate all the way into reports. Test this criterion with the statements from your own most difficult institutions, not with the vendor's sample files.
Asset Class Depth
Ask your vendor
- Are structured products (FCN, ELN, RCN, DRAN, CRAN, Autocallable) modelled as first-class asset types in the system, or booked as a bond or a cash flow?
- Are observation dates, coupon conditions and trigger determination derived automatically from contract terms, or maintained by hand in a separate calendar?
- How are PE/VC capital calls and distributions recorded, and can future funding dates be projected from the fund's tranche schedule?
- How are unlisted equity, real estate and art valued, how often are they updated, and who updates them?
Why it matters
The asset class list is the part that most often looks identical across vendors while differing most in substance. Many systems list structured products but handle them as an ordinary bond or cash flow, with terms, observation dates and trigger logic maintained in Excel outside the system. That gap between "on the list" and "in the system" only surfaces when you test with your own complex holdings. The test is direct: pick a structured product you actually hold, and ask the vendor to enter it fully and show every future observation date and possible cash flow outcome.
Multi-Entity Structures and Ownership Look-Through
Ask your vendor
- Can trusts, holding companies, foundations and limited companies be modelled in the system, and how many levels of nesting are supported?
- How are cross-entity consolidated reports produced, and can look-through be calculated by actual ownership percentage?
- How is an asset held jointly by several entities at different percentages handled?
- If the entity structure changes — say a new holding layer is added — does historical data have to be redone?
Why it matters
Family office assets are rarely held directly in an individual's name; trusts and multiple holding layers usually sit in between. If the system only supports the account level, multi-entity structures have to be approximated through account naming conventions, consolidated reports get stitched together manually, and every structural change means another round of rework. Entity modelling determines whether consolidated reports can be produced automatically. Both SFOs and MFOs hit this, but MFOs are more sensitive — they additionally need demonstrable data isolation between families.
Forward-Looking Capability
Ask your vendor
- Can the system list every known passive event over the next twelve months in one place (coupons, maturities, dividends, exercises, capital calls)?
- Are those events a manually maintained reminder calendar, or derived automatically from contract terms?
- When a trade or a plan changes, do all affected downstream future events recalculate automatically?
- How far out does the cash flow forecast run, which asset classes does it cover, and does it include private funding schedules?
Why it matters
Most systems are strongest at looking backwards: organising what has already happened into reports. But the real operational pressure in a family office is forward-looking — how much cash is needed next month for a capital call, which structured product is approaching a knock-in, which bonds mature soon and need a roll-or-redeem decision. This capability determines whether the system is a bookkeeping tool or an operating tool. The way to tell the difference is to ask whether events are entered or computed: an entered calendar fails silently when something is missed, whereas computed events cannot be missed as long as the contract terms are in the system.
Reporting Flexibility
Ask your vendor
- If we want to change how a chart is defined, do we configure it ourselves or file a request into your queue?
- How far does self-service configuration go — swapping fields, changing grouping dimensions, or altering the calculation itself?
- What is the delivery time and pricing model for custom reports?
- Can you replicate our existing PPT or Excel templates one-to-one, including layout?
Why it matters
Family office reporting definitions are highly individual and shift as family members' concerns shift. If every adjustment has to go through a vendor queue, reporting will permanently lag demand; but if self-service configuration only changes titles and colours, that is not flexibility either. The test material is the report inventory from section 2 — ask directly which of these can be replicated, in what timeframe, by whom, and at what price.
Data Operations Ownership
Ask your vendor
- Who maintains the data day to day: us, you, or a split?
- If you do, is it charged separately, how is it priced, and what is the response time commitment?
- Who investigates reconciliation breaks, and within what timeframe is a conclusion delivered?
- How is responsibility apportioned when data is wrong?
Why it matters
This is the item most easily left vague in a contract and most likely to become a long-running dispute after launch. Two systems can have identical feature lists, but who is responsible for getting data into the system and getting it right determines whether the family office needs to hire one or two more people. This implicit cost often exceeds the software licence itself, yet rarely appears on selection comparison tables. Settle the split, the pricing and the response times at contract stage rather than during implementation.
Security, Compliance and Data Sovereignty
Ask your vendor
- In which country and on which cloud is the data stored, and can we specify it?
- Which compliance frameworks do you meet (PDPA, GDPR, local regulatory requirements), and is there a third-party audit report you can produce?
- How are permissions structured, and can individual family members be restricted to only their own portion?
- Is activity logged down to the individual user and timestamp, and how long is it retained?
- Under what circumstances can your staff access our data, and how is that controlled and recorded?
Why it matters
Family office data is more sensitive than typical enterprise data and frequently spans multiple jurisdictions. Asking these questions during selection costs almost nothing; discovering after launch that the storage location or permission model does not meet requirements is extremely expensive to fix. Distinguish carefully between "we comply" and "we have been audited" — the first is a vendor assertion, the second comes with a report you can read.
Pricing Model and Exit Cost
Ask your vendor
- What is pricing based on: a fixed annual fee, a percentage of AUM, number of users, or number of positions?
- How does the fee change as AUM grows, and is there a cap?
- How is the implementation fee calculated, what does it include, and what triggers additional charges?
- When we leave, can we take the full structured dataset with us, in what format, and at what cost?
- What are the contract term, renewal terms and exit terms?
Why it matters
Under AUM-percentage pricing, growth in family wealth directly raises system cost, while the value the system delivers does not scale linearly with AUM — managing another billion does not mean the system did another billion's worth of work. Exit terms matter just as much: if data can only be exported as PDFs or incomplete tables, the system becomes a one-way door and switching vendors years later is painful. Writing the export format and its cost into the contract costs nothing now and pays off later.
Five Common Pitfalls
Underestimating Data Migration
Migration is the phase most likely to overrun, and the most frequently underestimated. The difficulty is not technical but historical: years of records in inconsistent formats, definitions that changed along the way, missing documentation, the same transaction failing to tie across different spreadsheets. If these are not resolved before migration they remain wrong in the new system, and they surface all at once because the new system validates more strictly. Specify in the contract what is in scope (how many years, which asset classes), who cleanses the data, and what the acceptance criteria are — and allow more time than the vendor quotes.
Watching Demos Before Defining Requirements
Demos showcase what each vendor does best. After three or four, requirements tend to become a composite of everyone's strengths that nobody can satisfy, and the decision degenerates into which demo flowed most smoothly. The correct order is to write the requirements per section 2, then walk every vendor through the same list, asking them to demonstrate with your data and your report templates.
Validating History but Not Forward Event Modelling
Signing off after reconciling historical positions and transactions is common practice, and it misses half the system. Matching history only proves the system can keep books. Whether forward event modelling is correct has to be tested with a structured product or a private fund you actually hold — have the system list all of its future observation dates or funding dates, then check them line by line against the contract terms. Left until after launch, this verification typically happens the first time an event is missed.
Overlooking the Long-Term Cost of Data Operations
Selection budgets usually count software fees, but the real recurring cost after launch is people: who collects statements, who enters data, who investigates reconciliation breaks. If that work stays with the family office, the system has replaced Excel with a nicer interface and saved no headcount. Compare options on three-year total cost including internal headcount, not on first-year licence fees.
Reconciliation Rework
Breaks in the first weeks after launch are normal; what damages the schedule is not planning for the rework. Breaks generally come from three places: errors already present in migrated historical data, definitions in the new system differing from the old ones, and field-mapping discrepancies in the ingestion layer. Put one to two months of post-launch reconciliation rework explicitly into the implementation plan, and agree who investigates breaks and how quickly conclusions are delivered.
FAQ
What is the difference between family office software and standard portfolio management software?
Standard portfolio management software is usually built around a single account or a single portfolio, centred on positions and performance. Family office software has to additionally handle three things: look-through consolidation across multi-entity, multi-layer ownership structures; complete recording and event modelling for non-standard assets (structured products, private funds, real estate, art); and highly individual reporting output. Without those three, the system degrades in a family office context into a bookkeeping tool that needs extensive Excel support.
How do SFO and MFO requirements differ?
An SFO cares more about asset class depth and reporting individuality, and its decision chain is short enough to customise around one family's preferences. An MFO adds two hard requirements: data isolation between families must be demonstrable, physically or logically; and one operating process must scale across multiple families, otherwise every new family means starting over. MFOs should focus verification on the permission model and on batch operating capability.
Why can't most systems handle structured products?
The difficulty is not bookkeeping but term parsing and event derivation. Every product's observation schedule, coupon conditions and trigger logic are written in its contract, and terms are expressed differently by each broker. Genuine support requires structuring the terms first, then deriving all future observation dates and possible outcomes from them. Most systems instead treat the product as a cash flow, leaving the terms outside the system — hence support appears on the list while tracking remains manual.
All-in-one platform or best-of-breed stack?
Family offices run both models. All-in-one gives one copy of the data, consistent definitions and single-vendor accountability; best-of-breed lets you use the strongest tool at each step, but requires interfaces to connect them, and when data goes wrong the investigation chain gets longer. The deciding factor is whether the family office has the capacity and appetite to maintain those interfaces: without dedicated technical staff, all-in-one usually has the lower long-run total cost.
How long does implementation take?
It depends on asset complexity and the quality of historical data, not on the system. With concentrated asset classes and tidy data sources, a launch in a few weeks is achievable; with multi-entity structures, substantial structured product and private holdings, and historical data needing cleansing, one to three months is typical — most of it spent on migration and reconciliation rather than configuration. Ask the vendor for a phased timeline with explicit acceptance criteria per phase.
What do you need to prepare for data migration?
Three things: a complete asset inventory showing the custodian and data source for each asset class; historical transaction documentation, especially contracts and cost basis records for non-standard assets; and explicit migration scope and definitions, including how many years, how cost basis is calculated, and which FX convention applies. The clearer these three, the less rework during migration.
How is family office software priced?
Two models dominate: an annual fee as a percentage of AUM, and a fixed annual fee. The former scales with asset size, the latter is decoupled from it. There is usually also a one-time implementation fee, and possibly separately priced data operations and custom development. Compare options on three-year total cost — licence, implementation, data operations and your own internal headcount — rather than on the first-year quote.
Where is the data stored and how do you assess compliance?
Establish the storage country and cloud provider first, then whether they can be specified. On compliance, distinguish between a vendor asserting conformance and holding a third-party audit report, and ask for the latter. If family members or assets span multiple jurisdictions, confirm separately how cross-border transfer is handled. Confirming this at contract stage is cheap; changing it after launch is not.
Do you need an in-house IT team?
If you choose a best-of-breed stack and need to maintain interfaces, at least one technical person is usually necessary. With an all-in-one platform where the vendor provides data operations, dedicated IT is not required — but you still need a business-side owner who decides on data definitions and reporting requirements, and that role cannot be outsourced.
How do you verify a vendor's AI parsing claims?
Test with your own files, not their samples. Pick ten to twenty of your most difficult real statements (the messiest layouts, scans, multi-currency ones), have the vendor parse them on the spot or within a time limit, then check accuracy field by field — paying particular attention to the type of error, whether it is occasional misrecognition or a format the system cannot handle at all. Also ask what happens when parsing fails: is there human review, or does it go straight into the books?
How Ginkgo Addresses These Eight Criteria
The eight criteria above are vendor-neutral. What follows describes Ginkgo's specific approach on each, for family offices currently evaluating.
Data Ingestion Breadth
Custodian data feeds connect automatically. For institutions those feeds do not cover, Ginkgo parses PDF statements, email attachments, contract terms and screenshot images using large language models combined with rule-based validation, fully managed — clients simply forward emails. The data layer is independent of any single custodian, so a feed disruption does not affect availability.
Asset Class Depth
Structured products (FCN, ELN, RCN, DRAN, CRAN, Autocallable, AQ/DQ warrants, options) are first-class asset types; terms are parsed into structured records and observation dates and trigger determination are derived automatically. PE/VC capital calls and distributions are recorded against the fund's tranche schedule. Unlisted assets such as real estate and art support custom valuation updates.
Multi-Entity Structures and Ownership Look-Through
Multi-entity modelling with multi-level nesting, automatic cross-entity consolidation and real-time multi-currency conversion. The asset classification tree is defined by the family office and the tree itself is adjustable. In MFO deployments each family's data is physically isolated.
Forward-Looking Capability
A universal asset event engine forecasts future passive events — knock-ins, coupons, dividends, capital calls, exercises, maturities — with N-day advance alerts. The ten-year cash flow waterfall is derived across all holdings, and downstream events recalculate automatically when any trade or plan changes.
Reporting Flexibility
Self-service configuration in 10 minutes, team-built custom reports in 1 day, one-to-one replication of existing PPT/PDF templates within 1 week; over 100 custom charts are live in production. Dashboards support 55 grouping dimensions and 1,000+ selectable fields.
Data Operations Ownership
Data operations are fully managed by Ginkgo, free during deployment, with no additional charge for ongoing data maintenance. Positions and transactions are reconciled bilaterally against custodian data daily, trade by trade, and Ginkgo investigates breaks.
Security, Compliance and Data Sovereignty
Permissions are layered by family and by member, activity is logged and traceable. The full security model and compliance positions are set out on the security page.
Pricing Model and Exit Cost
Fixed annual fee, no AUM-based surcharge, no price increase as AUM grows. The full trade ledger can be filtered on multiple dimensions and downloaded in one click, so data can be retrieved at any time.
Where Ginkgo Does Not Go
- No tax filing: Ginkgo supplies the positions, transactions and cost basis data tax advisers need, but does not produce tax forms or file returns
- No trade execution: Ginkgo does not take or place orders and does not provide order management; quote monitoring supports decisions only, with execution remaining at the broker or private bank
This is a general selection framework, not procurement advice. Family offices differ considerably in asset structure, entity architecture, operating processes and compliance requirements, so evaluate against your own situation. Section 6 is Ginkgo's own account of its capabilities; readers should verify it independently through a demo and a test run on real data.
Want to see how these eight criteria play out in a real system?
A 30-minute demo, run on your own holdings and your own report templates
Demo