In many of our conversations with Prophet users, the topic of sub-product codes, or SPCODE, often surfaces—particularly when discussing model structure and output interpretation. While SPCODE is a standard part of Prophet’s model point setup, how it is used can significantly impact both model flexibility and the range of analyses it can support. In this post, we share our perspective on best practices for using SPCODE effectively—especially when working with complex frameworks like IFRS 17.
Understanding the Role of SPCODE
SPCODE is a mandatory field in all Prophet model point files and must be placed in the first column. It is automatically recognized by Prophet—no separate variable is required to read it—and any positive integer up to 9999 can be used. For in-force runs (as opposed to new business processing), valid SPCODEs must be less than or equal to the “Last Sub-product Code for Existing Business” specified in the run structure.
Prophet uses SPCODE as a grouping key. When running a calculation, Prophet can generate:
- A combined set of results for all model points (SPCODE = 0), and
- Separate sets of results grouped by each unique SPCODE value.
For example, suppose a model point file contains SPCODEs 1, 11, and 21, each with 1,000 model points. Prophet will produce four result sets—one for each SPCODE and one combined result. If a variable is defined as cumulative, Prophet will automatically sum the values across model points sharing the same SPCODE.
Although other grouping techniques exist (e.g., by maturity year or using Flexible Results), grouping by SPCODE remains the most common and straightforward approach, especially in jurisdictions where detailed breakdowns are not required by regulation.
Our Recommendation: Use SPCODE for Grouping, Not as a Driver
In every Prophet model we develop, we consistently emphasize one key principle:
SPCODE should be used purely as a grouping mechanism—not as a driver of calculation or reporting logic.
This distinction becomes especially important in the context of IFRS 17. While it might seem convenient to use SPCODE to group model points into Insurance Contract Groups (ICGs) or other reporting cohorts, doing so risks locking SPCODE into a fixed meaning, thereby reducing its reusability for other types of analysis.
Consider these scenarios:
- You want to analyze profitability by distribution channel.
- You plan to assign test SPCODEs for model validation or sensitivity testing.
- You need to re-group policies by policy duration, cohort year, or region.
If SPCODE has already been hardcoded to represent ICGs or another specific dimension, it becomes difficult—if not impossible—to repurpose it for these additional uses. This leads to a more rigid model structure and increased maintenance overhead when analytical needs evolve.
Preserve Flexibility for Broader Use
It’s important to remember that Prophet models are not built solely for IFRS 17 valuation or any one reporting purpose. They are used across a broad spectrum of actuarial functions—including experience studies, stress testing, profitability tracking, and business planning.
Maintaining SPCODE as a neutral, analysis-driven grouping field ensures your Prophet model remains adaptable across different use cases. When set up properly, SPCODE gives users the freedom to regroup model points on demand—without conflicting with hardcoded business rules or structural assumptions.
In short, keeping SPCODE flexible means your model stays useful, relevant, and efficient—regardless of how your reporting or analytical needs evolve over time.
