The Many To Many Relationship in Secondaries

By Pulak Sinha

  • 5 mins read

Pulak Sinha, CEO: On Pepper

Secondaries fund managers face a unique challenge that most other portfolios will never have: a many to many problem. One deal may have many underlying funds as part of a transaction, and an underlying fund can be part of many deals which could be spread across multiple portfolios.

Many to many relationships are a class of problems that technical systems and databases hate to have. In fact, almost all modern relational databases like Oracle, SQL Server, or Informix explicitly prohibit creating such relationships. Many to many relationships create:

  1. Data redundancy problems where same data elements may need to be recorded in multiple places
  2. Data insertion, deletion, and updating difficulties as there are multiple records that can get affected in unintended ways

Why do Secondaries have this Problem?

The secondaries manager needs to manage each of her deals and the underlying funds as connected entities.

When reporting on the deals that she has in her portfolio, she needs to be able to provide a comprehensive return metric on the entirety of the deal. These return metrics could be the IRR (Internal Rate of Return), ROIC (Return on Invested Capital), or Cash on Cash Returns.

She also needs to provide returns on an aggregated basis to the underlying assets of her portfolio. She could have multiple instances of the same underlying fund, each bought at a different time, NAV, unfunded value, and cost.

How Do Secondaries Solve The Many to Many Problem?

The portfolio reporting system has to be explicitly designed to manage these scenarios as a naturally occurring business model and not try and walk around this complexity with “genius hacks”.

At Pepper, we designed our systems such that data is only entered once in the portfolio, encompassing every property of each underlying fund. This takes care of the data redundancy problem and is highly critical to the integrity of the platform. If the underlying fund has a change in its “name,” it needs to be updated only once. However, each transaction across each deal of that underlying fund is recorded and managed at its most granular level and treated separately. This allows the reporting engine to aggregate the best possible combinations required by the secondaries manager.

With Pepper, the secondaries manager can get her return for each individual deal and for each individual asset as a natural output.

 

To learn more about Pepper and our offerings, reach out to us or request a demo today. 

 

Related blog posts