For wealth management firms operating in Switzerland, where data is stored is only part of the question. They also need to understand how it is processed, who can access the systems that handle it, and how those systems operate across the platform.

Building a Swiss deployment for Addepar meant working through these requirements across the platform, from the underlying data infrastructure to the services that support reporting and client access. It also meant understanding that different firms have different expectations for data residency and operational control, and designing an approach that could accommodate those needs without fragmenting the product.

From hosting to data flows

The initial request sounded straightforward: Swiss hosting. But that description covered several distinct requirements. For commercial teams, it represented a need to serve firms with specific expectations around data residency. For engineering, it raised questions about regional infrastructure and service availability. And for security, it meant examining where sensitive information could be stored, processed, and accessed.

These distinctions are significant in wealth management as portfolio data often brings together account details, holdings, performance, client information, and reporting commentary from multiple sources. Protecting that information requires an understanding of how it moves through the platform as well as where the primary database exists.

A completed report, for example, is only one part of the process. The reporting service that generates it may create temporary files, while diagnostic logs can retain information when a job fails. Identity systems determine who can access services, and monitoring tools can expose information about the systems they support. We needed to understand these data flows and their operational implications before deciding how best to support the requirements of the Swiss market.

Mapping the architecture

Our first step was to map the systems involved, examining what data they received, where outputs went, what they retained, and who could administer them. This helped us identify the services that needed to operate within the intended regional boundaries, as well as the dependencies that required a different approach.

The work also highlighted the limits of treating data storage and data processing as the same problem. A service may not hold portfolio data permanently, but it can still process sensitive information or create records that need to be considered. Similarly, an identity or monitoring service may sit outside the core data model while playing an important role in how the platform is operated and secured.

Not every service we would ordinarily use was available in the target region. In practice, that means some data processing happens outside Switzerland, and we walk each firm through the full data flow so they can assess it against their own requirements. That meant assessing the architecture as a whole rather than assuming every component could simply be moved to a Swiss data centre.

The resulting approach combines regional infrastructure with separate cloud accounts and environments, regional policies, and access controls designed around operational needs. These elements work together to support the deployment's intended data and access boundaries. The objective was to extend Addepar's capabilities for the Swiss market while retaining a common platform and an operating model that our teams could continue to support.

Accommodating different configurations

Discovery also showed that firms would not all approach data residency in the same way. Some could work within a shared operating model, provided their requirements around regional data storage and administrative access were met. Others needed stronger infrastructure separation or additional control over encryption.

We wanted to establish a clear regional baseline while allowing for additional separation where a firm's requirements justified it. Making every possible control part of the default configuration would introduce unnecessary complexity for firms that did not need it. Equally, designing only for the simplest requirements would limit the deployment's ability to serve firms with more demanding needs.

Defining those distinctions early helped us make deliberate decisions about the architecture, the product capabilities to prioritise, and the trade-offs involved.

Building for the next market

The Swiss deployment reflects a broader challenge in wealth management technology — supporting firms across jurisdictions with different expectations around data, infrastructure, and operational control.

Those requirements cannot always be addressed by replicating the same configuration in another region. Local service availability, client needs, and regulatory obligations all influence the design. The work in Switzerland has given us a clearer approach to assessing those differences. By starting with client requirements, mapping how data moves through the platform, and identifying the controls needed at each stage, we can make better-informed decisions about how to extend Addepar's capabilities into new markets.

That foundation matters as we continue to support wealth management firms with different operating models and increasingly specific requirements for how their data is handled.

If your firm has data residency requirements in Switzerland, reach out to your Addepar representative to walk you through the data flows for your setup.