What Is a Product Master? (And Why You Need One.)

Master data management (MDM), long a core capability at investment management firms, helps ensure that data is accurate, complete, timely, and used in a consistent manner, making it a critically important part of the investment management world. MDM differs from data warehousing because it focuses on the current values of the data and not its history. Over the past five to seven years, MDM capabilities have spread to product, client service, and distribution teams. These teams are ditching spreadsheets and other tactical solutions for robust masters to help manage their data. Product reference data is the leading data domain that has received increased attention from these client- and prospect-facing functions. In this article, we explain what a product master is, the benefits of implementing one, adoption trends, the vendor landscape, and the attributes of investment managers that have taken the plunge.

What Is a Product Master?

MDM systems, commonly called “masters,” are repositories that house a golden copy of data for one or multiple data domains. Industrial-strength product reference data masters (aka product masters) leverage a database to support the storage requirement. They also have input screens and other data-ingestion capabilities for capturing data, data validation rules, capabilities around data access and distribution, and permissioning features. A product master allows operationally oriented individuals or teams that sit in or close to the product function to capture data values during product onboarding and to ensure that defined standards for data quality are upheld.

How Is a Product Master Different From Other Masters?

First, let’s dissect how product reference data is different from two commonly mastered data domains. Product reference data differs because it originates within the firm, each attribute has a single source, text is prevalent, and data values are fixed for long periods of time.

An MDM system typically includes three groupings of functionality ─ data collection, data validation/workflow, and data distribution. While firms require all three for product reference data, the requirements for each are slightly different.

Since firms create product reference data internally and its unique to each investment manager, firms often cannot collect it through automated data ingestion (e.g., batch ETL, messaging, API). In some instances, a firm may source the data from an internal application, but the most common method is via free-form text boxes or a dropdown selection. As a result, the product master requires a flexible and intuitive user interface for data entry.

Product reference data is mostly static, and each attribute comes from one source. Consequently, there’s less sophistication with data scheduling and transformation than with security reference data or prices. Data quality and validation rules also tend to be simple ─ for instance, matching algorithms or waterfall logic aren’t needed for product reference data.

From a generic MDM workflow perspective, requirements around monitoring the status of the data and comprehensive audit trails are equally important for product reference data. While it might seem that workflow would be a lesser need since product reference data doesn’t change much, this isn’t necessarily the case. That’s because within the lifecycle of a product (ideate, design, build, maintain, change, close), data implications arise throughout. During the early stages (onboarding) of a new product, certain data fields tend to be iterative.

Multiple parties also may get involved in the contribution and review of different product reference data buckets, so granular access permissions, along with defined approval workflows, are also important. While most commercially available product master systems don’t yet support end-to-end workflow for product onboarding out of the box, vendors have this capability on their radar now that many investment managers have begun showing a level of interest in it.

Downstream applications, publications, websites, and consuming parties trust that product information is up to date. Product reference data doesn’t often change, but when it does it helps if it’s updated in the master as soon as possible. Changes to a product, such as benchmarks and fees, are key examples of revised data values that need to be pushed downstream once identified.

Benefits of a Product Master

Cutter Associates has helped several large multi-national asset managers identify product-related gaps, plan for a product master, and select a tool. Some benefits that firms have achieved by implementing a product master include the following:

• Increasing productivity by managing data through a single application and flexible data model, allowing for a holistic view of products
• Minimizing misinterpretation and misrepresentation of a product and its data by enabling a single version of truth
• Reducing risk by eliminating manual efforts in the acquisition and consumption of product data, enabling higher data quality and quicker turnarounds
• Providing audit of all product changes since inception
• Establishing a foundation for addressing consumption use cases that originate in product teams or further downstream
• Playing a part in streamlining workflow for product onboarding and product changes

Product Reference Master Adoption

For the first half of the 2010s, most firms prioritized mastering other domains. But now, many firms have turned their focus to client, account, and product reference data initiatives. The explanation for this shift might be two-fold ─ first, firms are taking a rational approach by blocking and tackling the mastering and governance of a laundry list of data domains and product data happens to be next on the list for many of them. In the past, the pricing data domain may have been a major source of errors and business risk for a firm, but that’s mostly out of the way. For this domain, a solution has been implemented, a data operations team is in place, and pricing data is formally managed under the enterprise data governance regime.

The second reason is that the vendors in this space have also evolved. While investment managers have come a long way, vendors have been consistently listening to their client base and adapting their platforms to address their clients’ biggest challenges, and now product reference data is at the forefront.

A Look at the Vendor Landscape

Two types of vendors have met with success in this space for investment managers ─ MDM players that initially built their offerings around the more mature data domains such as security reference, pricing, holdings, and transactions, and an emerging class of vendors that specialize in the investment product management use case.

Vendors can distinguish themselves in a variety of ways. Some are more experienced with the not-so-common investment vehicles found in specific parts of the world. Others have more experience with complex investment offerings such as funds of funds, models, and esoteric solutions. Vendors also differ in the data models they feature. Data models can be partially or fully out of the box for product reference data, and some come with a blank slate that requires moderate-to-heavy configuration during implementation.

In either case, vendors need to properly tailor their solutions to their investment manager clients’ custom requirements and workflows, while supporting their entire suite of investment vehicles and product offerings (e.g., pooled products, individualized products, solutions, services, etc.).

Are You a Good Fit for a Product Master?

While this is a complex question to answer, most investment managers that have implemented a product master possess at least one of the following attributes:

• High number of investment vehicle types (often domiciled across multiple regions)
• Complex product mix, including two to three of the following: institutional separate accounts, pooled products, and/or solutions
• Growing product onboarding volumes, spurring the need for more automated workflow

Firms that have turned to vendors for product mastering may already use that same vendor for an adjacent data domain where simplification of their target-state systems architecture and data integration is a benefit. This could also potentially allow for a smoother platform learning curve adjustment as well as reduced implementation and licensing costs.

The Bottom Line

Of course, it takes a fair amount of discovery work to determine if your firm is a good fit for a product master. But a system by itself won’t solve all your firm’s challenges. Data and processes must be appropriately enhanced to support the new technology. A combination of optimized systems, data, and processes overlaid with formal data governance can elicit material improvement and alleviate the product-related pain you feel today.

Want to learn more? Read our whitepaper, Implementing a Product Master? Here Are 8 Best Practices to Consider Before Getting Started. If you would like to speak with a Cutter consultant, contact us at [email protected].