The Family Office Is an Information System

Why a family office should be designed as an information system spanning people, mandates, records and technology—not as a loose collection of trusted.

The answer

A family office is often described through its people: investment director, controller, assistant, lawyer, tax adviser, trustee, banker, household staff. That description misses the mechanism.

A family office is often described through its people: investment director, controller, assistant, lawyer, tax adviser, trustee, banker, household staff. That description misses the mechanism. The office is an information system. It receives signals, transforms them into decisions, moves instructions across boundaries and retains the evidence on which the family’s affairs depend. Some components are software. Many are human. The failure usually appears in the connections between them.

Trust does not create architecture

Private institutions are built on long relationships. That is often a strength. It also allows critical information flow to remain undocumented because everyone believes the right person knows. A bank sends a statement to an assistant. The assistant forwards it to an accountant. The accountant maintains a private workbook. An investment decision is recorded in an email. A lawyer holds the current entity chart. A technology provider manages access without understanding the legal structure. The principal receives a polished quarterly pack and sees none of the machinery. This system can operate for years. It fails during succession, dispute, incident or provider change—exactly when institutional memory matters most.

Model the office in six layers

  • Sources: banks, custodians, advisers, companies, properties, people, devices and public records.
  • Records: contracts, statements, identity evidence, minutes, valuations, correspondence and working papers.
  • Authority: mandates, ownership, signing rules, approval limits and emergency succession.
  • Workflows: how information becomes a decision, an instruction and a completed action.
  • Interfaces: portals, email, messaging, calls, meetings, APIs and manual transfers.
  • Evidence: the durable record of source, decision, execution and reconciliation.

A strong office knows the authoritative location for each material fact and the owner responsible for keeping it current.

Separate the record from the report

A report is a view. It should not become the only surviving record. Quarterly packs flatten complexity into a readable narrative. That is useful for governance but dangerous as an information architecture. A chart without source lineage, a valuation without date and method, or a risk flag without an owner cannot support later scrutiny. Preserve the underlying source, transformation and approval. The office should be able to answer not only “what did we believe?” but “why did we believe it, who accepted it and which version was operative?”

Authority should travel with the workflow

A task list says what must happen. It may not say who can bind whom. For consequential workflows—payments, distributions, acquisitions, entity changes, private disclosures, account recovery—attach the authority rule to the process. The person preparing the action should see the required approver, verification route, limit and evidence. Do not leave the rule inside a separate legal folder no operator opens.

Design the human APIs

People are interfaces. A principal issues a voice instruction. An assistant translates urgency. An adviser interprets intent. A vendor asks for confirmation. Each handoff changes the information. Standardise only where standardisation protects meaning:

  • A high-value instruction format that records purpose, amount, beneficiary, authority and verification.
  • A decision record that distinguishes facts, assumptions, advice and final judgment.
  • A transition pack for providers and personnel.
  • A material-change notice when ownership, mandate, risk or contact details shift.
  • A concise exception record with an owner and expiry.

The objective is not paperwork. It is to prevent consequential meaning from depending on memory and tone.

Measure concentration and fragility

The office should be able to see where one person, provider or platform holds too much of the system.

  • Which records exist only in an adviser’s environment?
  • Which workflow stops if one person is unavailable?
  • Which administrator can access several otherwise separated domains?
  • Which manual spreadsheet silently determines a major report?
  • Which counterparties rely on a relationship instead of a current mandate?
  • Which facts cannot be reproduced from authoritative sources?

These are architecture questions with financial and legal consequences.

Build for change

A family office is not a static organisation. Marriages, births, deaths, moves, transactions, disputes, new jurisdictions and new generations alter both authority and information sensitivity. The system must absorb those changes without rebuilding from private memory each time. Designing the office as an information system does not make it impersonal. It protects the people from carrying institutional continuity alone. It allows trust to survive changes in personnel, technology and circumstance. The real test is simple: can the institution explain how a material fact becomes a binding action—and reproduce the evidence after the person who handled it has gone?

Sources

  1. FINMA: Revised circular on operational risks and resilienceFINMA: Revised circular on operational risks and resilience

    Primary authority

  2. NIST SP 800-207: Zero Trust ArchitectureNIST SP 800-207: Zero Trust Architecture

    Primary authority

  3. Swiss FDPIC: Data securitySwiss FDPIC: Data security

    Primary authority

Ross BelhommePartner, Svperior / Legal

Adam J. De Collibus

Adam co-founded Svperior and leads systems engineering from requirements through implementation. His work connects architecture, implementation, deployment, and operating discipline across complex environments where failure must be anticipated and technical capability must remain dependable under pressure.

Systems engineering / Technical architecture / Production operations / Operating resilience

Need to apply this to a specific situation?

Send us the initial context. If the matter fits, we will respond directly.

Send private inquiry