Design Once, Distribute Everywhere: A Better Way to Configure Financial Products

Design the service: Stage one of the KidbrookeONE lifecycle

Ask three teams inside a financial institution to describe the same savings product and you can easily end up with three slightly different answers. The pricing sits in one spreadsheet, the contribution and tax rules live in a policy document, and the projection that tells a customer what their money might become is buried in whatever calculation engine happened to be free when the journey was first built. None of those answers is wrong on its own. However, they drift apart, and someone has to notice before a customer does.

In the first article in this series, we described KidbrookeONE as one connected platform for designing, distributing and administering financial journeys. This article stays with the first of those stages, design. Before a customer can buy a product or an adviser can recommend one, the institution needs a single, reliable definition of what the product is, the local pension and tax rules that govern it, and a projection engine configured to show where it might lead.

Product universes, risk profiling logic, fees, contribution rules, local pension rules and the assumptions behind projections all need to stay consistent across every channel and partner interface. When those elements are scattered across spreadsheets, product documents, calculation engines and different applications, a change made in one place must be copied into all the others by hand. But each copy is another chance for the versions to move apart.

Two of these are where the hard problems usually sit. Local pension and tax rules change from one market to the next, and getting them wrong is costly. A projection is only worth showing if customers can trust the numbers behind it. The platform builds both in as native capabilities: a rules engine that encodes real local logic, and a simulation engine that turns a product definition into thousands of possible future scenarios. Much of the rest of the design stage exists to feed those two.

All of this works because KidbrookeONE treats product design as versioned configuration rather than an engineering ticket. Define the product, its rules and its projection assumptions once, and then every relevant journey and channel reads from that same definition. Four capabilities do the work, and they can be adopted together or one at a time.

Product Universe & Configuration

Product Universe & Configuration gives an institution a central source of truth for its investment products, pensions, insurance products and model portfolios. Instead of maintaining several versions of the same information across disconnected spreadsheets and applications, teams govern products in one place, adding, editing or retiring a fund, model portfolio or product through a single interface or the API. From there the change flows out automatically to the customer portals, adviser tools and distributor platforms that rely on it, so nobody needs to update each one by hand. The platform can hold several product universes side by side, which lets a firm run a different approved list for each platform or client segment, build model portfolios and link them to the right universe, and handle fees that differ from one platform to the next. Every change is versioned, leaving a clear record of what changed and when. A single definition carries its pricing, classifications, fees and lifecycle rules, and the value of that grows as an organisation launches new products, moves into new markets or runs several propositions at once.

Market & ESG Data Hub

Configuration becomes far more useful once it is connected to reliable market information. The Market & ESG Data Hub connects once to the outside sources a firm depends on, the fund and instrument data, prices and sustainability information that often sit with several different third-party providers, then cleans and enriches that data and serves it to everything downstream through one set of APIs. The result is a common data layer, so product analysis, portfolio comparison, advice, illustrations and reporting all draw on the same underlying data, and no single application is left to integrate with each vendor on its own or interpret the figures differently. Customers never see this layer, yet the discipline it imposes shapes almost every interaction that follows.

Pension & Tax Rules Engine

Financial products live inside local regulatory, pension and tax frameworks, and those frameworks are rarely optional. They shape what a customer can contribute, how benefits are treated and how an outcome must be presented, and they differ in every market. Rather than bolting approximations onto each journey one at a time, KidbrookeONE applies native pension and tax rules as part of the underlying product and analytical configuration. The rules for the markets we have already mapped, including Sweden, Switzerland, the UK, the UAE and Singapore, are ready to use, and a new market can usually be added in just a couple of weeks, with a flexible set-up so a firm can maintain and adjust the rules as regulations change. For an institution operating across several markets or domiciles, local logic is then reflected the same way in planning, advice and product journeys, wherever the customer happens to be.

Scenario & Projection Engine

Once the product, its data and its rules are in place, a different question comes into view: what could this product mean for the customer?

The Scenario & Projection Engine generates thousands of economic scenarios using Monte Carlo simulation, combining assets, liabilities, income, pensions and tax into a single probabilistic view of where a customer might end up financially. Three things set it apart. It is granular, modelling the underlying risk factors in enough detail to reflect a specific product universe rather than a generic market. It is fast, with calculations that scale from one client to an enterprise. And it is modular, so a firm can apply its own house views or draw on Kidbrooke's global outlooks. Shown visually inside a journey, projections like these change how well customers grasp risk and the possible downside, which is one of the harder things to communicate in financial services. This is where product design meets customer decision-making.

One definition, every channel

When these four capabilities share the same foundation, the quote a customer sees, the illustration an adviser builds, the projection in a self-service journey and the contract that is eventually issued all trace back to the same definition, the same rules and the same analytics. There is no separate version kept for the app, another for the adviser desktop and a third for the back office.

The effect is easiest to see when something moves. Add a fund to an approved universe, adjust a fee, change a tax rule or update a projection assumption, and the change takes hold everywhere the definition is used, at once. A customer checking a forecast, an adviser building a recommendation and the operational record behind the contract are all reading from the same figures. When those numbers agree, customers have a reason to trust what they are shown.

None of this is all-or-nothing. The design stage is modular, so a firm can take the components it needs, start from scratch, or build out its journeys with Kidbrooke's components over time. A single, well-managed definition keeps model risk in check, and launching a new product or entering a new market becomes a matter of extending the configuration, not rebuilding the same logic in every channel. Design becomes the point where consistency, governance and speed are settled, long before a customer ever sees a journey.

Coming next

Defining the product is the starting point. The next article follows that definition outward into the first major distribution experience: the connected digital journeys that carry a customer from first click through onboarding, self-service and ongoing servicing. We will look at how a well-designed product becomes an experience a customer can use and trust.