The build-or-buy choice for a wealth management platform is made per component, not once for the whole stack. The table below sets out the question, the Swiss touchpoint and the evidence to ask for in each of five components, and leaves the verdict to your own context.
This guide is for CIOs, COOs and heads of private banking at Swiss private banks, independent wealth managers and family offices who are weighing wealth management platform development against a licensed product.
Key Takeaways
- Split the platform into onboarding, portfolio and orders, reporting, client portal and integrations, and take a separate build-or-buy decision for each.
- A hosted platform can count as an outsourcing, so the institution assesses each outsourced function itself, where the FINMA outsourcing rules apply to it.
- The Federal Council has decided, for now, to refrain from regulatory requirements for open data interfaces, so integrations stay a commercial and technical choice.
- AI features inside the platform fall under FINMA’s supervisory expectations and under the FADP, whatever technology is used.
- Ask every vendor, and your own team, for documented evidence per component before you decide.
Table of Contents
- The decision table: component by component
- What a wealth platform covers and why the split matters
- Swiss rules that shape the choice
- How to run the decision
- Our perspective
- How S-PRO helps with wealth platform development
- FAQ
- Sources
The decision table: component by component
Each component has its own build-or-buy question, its own Swiss touchpoint and its own evidence to request. The table gives a starting frame; it does not rank the options.
| Component | Build/buy question | Swiss touchpoint | Evidence to ask |
|---|---|---|---|
| Onboarding | Is your onboarding flow a differentiator, or a standard process a product already covers? | Client segmentation and suitability duties under FinSA; AML and KYC rules; FADP for the personal data collected | Data flow diagram, audit trail sample, how client categories are stored and changed |
| Portfolio and orders | Do you need your own portfolio logic and order routing, or a proven core with configuration? | Suitability and appropriateness reviews under FinSA; operational risk and resilience expectations in FINMA Circular 2023/1 for banks and securities firms in scope | Reconciliation controls, recovery objectives, change-management records |
| Reporting | Are your reports standardized, or tailored per client segment and mandate? | FinSA documentation duties; FADP on data minimization and access | Report templates, data lineage from source to figure, access logs |
| Client portal | Does the portal carry your brand and advisory relationship, or only deliver documents? | FADP; cloud and cross-border data rules; information security | Hosting location, sub-processor list, penetration test summary |
| Integrations | Do you need open interfaces to custodians, market data and CRM, and who maintains them? | No regulatory requirement for open data interfaces for now (Federal Council, 12 December 2025); statutory duties remain an option | Interface documentation, versioning policy, exit and data-return terms |
Treat the last column as a request list. A vendor or an internal team that can answer it with documents is easier to compare than one that answers with a presentation (for AI pilots in wealth management, see how to compare vendors for a fixed-price AI pilot).
What a wealth platform covers and why the split matters
A wealth management platform brings client data, portfolios, orders, reporting and communication into one working environment for relationship managers and clients. Most Swiss institutions do not need to decide on all of it at once.
The pages that rank for this topic mostly describe feature lists and a generic development process. For a Swiss institution, the more useful question is where your own logic creates value and where a standard product is enough. Components with a fixed regulatory shape, such as ledger-like record keeping, tend to suit configuration of an existing product. Components close to your client relationship, such as the advisory workflow and the portal experience, are where custom work can carry your way of serving clients.
That is a frame, not a rule. Your size, your custody model and your existing systems change the answer. A family office with one custodian and a small team faces a different choice from a private bank with several legacy systems.
Onboarding
Onboarding is where client data first enters the platform, so it sets the quality of everything downstream. Swiss financial service providers segment clients into private, professional or institutional categories under the Federal Act on Financial Services (FinSA), which entered into force on 1 January 2020. Your onboarding component has to store that segmentation and let you change it with a trace.
The build question is whether your KYC and onboarding flow is specific enough to your client base to justify custom work, or whether a product with configurable steps covers it. Ask for a sample audit trail and a data flow diagram that shows where personal data sits and who can read it.
Portfolio and orders
This component holds positions, models, mandates and order flow. Investment advice and portfolio management carry suitability and appropriateness reviews under FinSA, in the version in force from 1 August 2021. The platform has to make those checks visible, not leave them in a side document.
For banks and securities firms in scope, FINMA Circular 2023/1 on operational risks and resilience is the reference. Margin numbers 53-54 require an up-to-date inventory of ICT assets, including interfaces to significant external service providers, and margin number 82 requires particularly thorough due diligence on service providers that can process or view critical data. The circulars are listed on the FINMA circulars page. Ask for reconciliation controls, recovery objectives and the change-management record for the component.
Reporting
Reporting is often the best candidate for a build decision when client segments need different formats, and a product decision when reports are standard. Either way, every figure should trace back to its source system.
Ask for report templates, the data lineage behind them and access logs (for the data-aggregation principles behind this, see BCBS 239 compliance for banks). Under the FADP, access to client data in reports follows the same minimization logic as anywhere else in the platform.
Client portal
The portal is the part your clients touch. It is also where hosting decisions become visible: where the data sits, who the sub-processors are and how access is secured.
The Federal Data Protection and Information Commissioner (FDPIC) states that a company assigning data processing to a cloud provider remains responsible for ensuring the processor complies with data protection requirements. The same page says that if personal data is processed in a country without an appropriate level of protection, steps must ensure appropriate protection for the cross-border disclosure. So the portal decision includes a hosting location and a sub-processor list, not only a design.
Integrations
Integrations connect the platform to custodians, market data, CRM and payment systems. On 12 December 2025 the Federal Council decided, for now, to refrain from regulatory requirements for open data interfaces in finance; its review of the existing market-led approach was mixed, and statutory duties remain an option for the future.
For you, this means interfaces remain a commercial and technical choice today. Build the integration layer so that a later statutory duty would not force a rebuild: documented interfaces, versioning, and clear exit and data-return terms with every provider.
Swiss rules that shape the choice
Swiss rules do not decide build versus buy for you, but they decide what evidence you need either way. Three areas matter most: outsourcing, data protection and AI.
Outsourcing: a hosted platform may be one
A hosted or software-as-a-service platform can count as an outsourcing when the provider takes over a material function on its own and on a lasting basis; the institution then stays responsible towards FINMA as if it performed the function itself. For institutions in scope, FINMA Circular 2018/3 on outsourcing is the reference, in particular margin numbers 14, 18.1, 20-21 and 33. Check the scope first: the circular applies to defined categories of institutions, and not every wealth manager falls under it.
In practice, assess each function separately. Onboarding hosted by one provider and reporting hosted by another are two outsourcing questions with two sets of evidence, not one.
Data protection: FADP and cloud
The FDPIC called for a data protection impact assessment when personal data is processed in the cloud, and the revised FADP calls for one when processing is likely to entail a high risk, as set out in the FDPIC’s 2022/23 activity report. For a wealth platform that holds financial and family data, plan the assessment before the architecture is fixed, not after.
AI inside the platform
The FDPIC states that the FADP applies to AI processing of personal data, regardless of the technology used. On the supervisory side, FINMA Guidance 08/2024 sets out what the authority expects on AI governance. Its April 2025 survey of around 400 supervised institutions found that about half use AI or have first applications in development, and FINMA recommends contacting it in good time before using AI in critical processes or to calculate regulatory parameters. Both are available through FINMA’s publications.
If you serve clients in the EU, the EU AI Act also matters. Regulation (EU) 2026/1744 (AI Omnibus) has been in force since 27 July 2026. Stand-alone high-risk obligations (Annex III) apply from 2 December 2027, and high-risk AI embedded in products (Annex I) applies from 2 August 2028; the dates are on the European Commission’s AI Act page. For each AI feature, check Annex III against the use case rather than assuming a category.
How to run the decision
A short, written process beats a long debate. This checklist works for a committee of the CIO, COO and head of private banking.
- List the five components and name an owner for each.
- For each, write the build-or-buy question in one sentence, using the table above.
- Mark which components are an outsourcing of a function and, for institutions in scope, which FINMA circular applies.
- Request the evidence listed in the table from each candidate vendor and from your internal team.
- Record the decision per component, with the reason and the exit path.
- Review the record when your custody model, client mix or regulation changes.
A mixed outcome is normal: a licensed portfolio core, a custom reporting layer, a custom portal and a thin, documented integration layer. The point is that each piece has a reason on file.
Where teams get stuck
The common stall is deciding for the platform as a whole. A vendor demo of a strong portfolio engine then pulls the portal and reporting decisions along with it, although those components may call for different answers. Splitting the decision first removes that pull.
The other stall is leaving AI to the end. If relationship managers are meant to get an AI copilot, the data model, the audit trail and the governance have to be designed with that in mind from the first sprint.
Facing a platform decision with several legacy systems behind it? Our engineers can walk through the five components with your team and map them to build, buy or mix. Talk to our engineers about your fintech software development needs.
Our perspective
We approach wealth platforms as a set of components with different lifespans. The client relationship layer, meaning advisory workflows, the portal and RM tooling, changes fastest and is where an institution’s own way of working shows. The record-keeping core changes slowly and is rarely worth rebuilding.
That is why we start from the decision table, not from a technology. For each component, we ask what evidence the institution will need in front of its board, its auditors and its supervisor, and then design the build or the integration to produce it.
AI agents and RM and wealth copilots belong in that design from the start. An assistant that drafts a client review is only useful if the data behind it is clean, access is logged and a human signs off. We build those controls into the platform, not around it.
For a wider view of how Swiss banks choose engineering partners, see our guide to banking software development companies in Switzerland.
The S-PRO team
How S-PRO helps with wealth platform development
We are an international Swiss-American firm with offices in Zurich (Löwenstrasse 45, 8001 Zürich) and Salt Lake City, and global delivery, founded in 2014, with 250+ engineers and ISO 27001 and ISO 27701 certification. Our work for wealth managers and banks covers fintech software development, digital banking platforms, core and legacy modernization, and RM and wealth copilots.
We build each solution on our own agentic platform, S-PRO Agents, and can run it as a service. If your decision table ends in a mix of build and buy, we can take on the components you build and the integrations between them. See our fintech software development offer for the starting point.
FAQ
Should a Swiss wealth manager build or buy its platform?
Neither answer fits the whole platform. Decide per component: onboarding, portfolio and orders, reporting, client portal and integrations each carry their own question, Swiss touchpoint and evidence. Many institutions end with a mix, for example a licensed core with a custom portal and reporting layer.
Is a hosted wealth platform an outsourcing under FINMA rules?
It can be. A hosted platform can count as an outsourcing when the provider takes over a material function on its own and on a lasting basis; the institution then stays responsible towards FINMA as if it performed the function itself. For institutions in scope, FINMA Circular 2018/3 is the reference. Check first whether the circular applies to your type of institution.
Does Switzerland require open interfaces for wealth platforms?
No. On 12 December 2025 the Federal Council decided, for now, to refrain from regulatory requirements for open data interfaces, after a mixed review of the current approach. Statutory duties remain an option. Document your interfaces so that a future duty would not force a rebuild.
What does FINMA say about AI in a wealth platform?
FINMA Guidance 08/2024 sets out what the authority expects on AI governance. Its April 2025 survey found that about half of the around 400 institutions surveyed use AI, and FINMA recommends contacting it early if AI is planned for critical processes. The FADP also applies to AI processing of personal data. Assign an owner and keep records for each AI feature.
Sources
- Federal Act on Financial Services (FinSA), Fedlex
- Federal Act on Financial Services, version in force from 1 August 2021, Fedlex
- FINMA circulars
- FDPIC: Outsourcing of data processing
- FDPIC: 30th activity report 2022/23
- FDPIC: Artificial intelligence in everyday life
- European Commission: AI Act regulatory framework
- FINMA Circular 2023/1 Operational risks and resilience – banks (PDF)
- FINMA Circular 2018/3 Outsourcing (PDF, German)
- FINMA press release, 24 April 2025: survey on AI use
- Federal Council, 12 December 2025: implementation of open finance in Switzerland
- EUR-Lex: AI Omnibus Regulation (EU) 2026/1744
Last updated 4 November 2026
Ready to map your own platform? Request a discovery call with S-PRO and bring your component list.
Subscribe
Thank you!
Get ready! You will receive handpicked content right to your inbox.
