Multi-country insurer: framework variation without upgrade pain
A global property and casualty insurer operates in 12 countries, with three product lines (motor, home, commercial) and a 14-year-old policy administration platform. The Pega Center of Excellence has built a common underwriting framework used by all countries, but each country has 30-80 local regulatory and product variations. Releases occur every six weeks; production hotfixes are frequent because local overrides sit in the framework ruleset. Reuse is reported at 42%, and upgrade rehearsals take 11 days. The CIO wants a single application stack on Pega Cloud, with country teams able to deploy local changes without waiting for the central release, while preserving a common data model and shared case lifecycle. The program has 18 months and 60 builders across four regions. Data residency requires EU policy data to remain in the EU. Audit requires evidence of which ruleset version produced each decision.
1. Recommend the enterprise class structure and application stack. Explain where shared case lifecycle, common data, and country-specific rules should live, and why.
Read the worked answer
I would use a three-level application stack: an enterprise framework at the Organization layer, product frameworks at the Division layer, and country implementations at the Unit layer. Shared case lifecycle, party/product data model, and enterprise reporting belong in the Organization framework because they change slowly and must be consistent. Product-specific underwriting and rating rules belong in Division frameworks. Country implementation layers hold regulatory overrides, local UI labels, and country data classes. Country teams must not edit framework rules; they specialize case types or use extension points such as when rules, data transforms, and declare expressions. This directly addresses the current failure mode: local overrides inside the framework ruleset cause hotfix conflicts and 11-day upgrade rehearsals. The tradeoff is more classes and a stricter promotion process, but it gives reuse a chance to rise because the framework remains upgradeable. I would not create a separate application per country unless data residency forces a separate runtime; even then the same framework artifact should be deployed.
2. Design the ruleset, branch, and hotfix strategy so a country can deploy independently without destabilizing the shared framework.
Read the worked answer
Use separate rulesets per layer: enterprise framework rulesets, division rulesets, and country implementation rulesets. Countries work in application branches off their implementation ruleset, not the framework. A country release pipeline promotes only its implementation ruleset and its associated data classes; framework changes require central review and a minor or major framework version. Hotfixes should be patch rulesets with narrow prerequisites, not direct edits to the base ruleset. Use ruleset prerequisites so country rulesets depend on a minimum framework version, and skim patches on upgrade. For emergency regulatory changes, allow a country patch ruleset but require it to be reconciled before the next framework release. This costs governance overhead, but it prevents a local override from blocking an upgrade. I would also enforce guardrail compliance and automated application validation in the pipeline.
3. How would you satisfy EU data residency and audit requirements for ruleset-version traceability?
Read the worked answer
Data residency is a deployment boundary, not just a class-design issue. I would deploy an EU-region runtime for EU countries, with the shared framework distributed as a versioned application artifact. EU policy data, documents, and case history stay in the EU database; non-EU reporting receives only aggregated, approved data. Cross-border services must not copy case data into non-EU queues or logs. For audit, record at case level the application name, ruleset name and version, operator, timestamp, and decision outcome for each status or underwriting decision, and write it to an append-only audit store. Do not rely on the current case status alone; the audit must show which ruleset version produced the decision. This is more work than a single global runtime, but it meets residency and gives defensible evidence during upgrades.