P&C Property Business Services

Mainframe Rating Engine & Insurance Systems

Context

Led development and modernization of a US P&C insurer's Property insurance applications as Tech Lead and Project Coordinator. Translated complex mathematical rating algorithms (PL/I and IMS-DB) into understandable system requirements, working closely with Underwriting and Actuary. Migrated the legacy rating engine from the Corporate Rating System on Mainframe to the Ratabase rules engine. Managed high-volume IMS databases handling 1M+ transactions per hour.

Constraints

• No write freeze — the carrier couldn't pause new policy writes or rate changes while the engine was being replaced; the actuarial business needed to keep filing and changing rules during the migration.
• Regulated filings — every translated rate had to produce the same premium cent-for-cent as the mainframe, because real customer checks (including several-hundred-thousand-dollar refunds during re-rate cycles) were going out based on the results.
• No consolidated owner for the rule set — the 100+ rating procedures had been authored over two decades by actuaries who had since rotated out; there was no authoritative spec and no single SME who could produce one.
• IMS-DB high-volume workload — 1M+ transactions per hour kept moving while the rules were being re-platformed onto Ratabase; performance characteristics couldn't degrade during the migration.
• Coordinated 114+ engineers across US, India, and Europe — the choreography had to work across time zones, language fluency, and a mix of mainframe-native and modern engineers.

Architecture

Data Model

The rating engine fuses two systems at runtime — a rules system (the actuarial logic) and an execution system (the engine that runs it). On the mainframe, those were inseparable: the rule was a PL/I procedure, the lookup was an IMS-DB hierarchical segment, the version control was the source control of the program. The IMS-DB side held the rating factor lookups — territory tables, construction class tables, peril modifiers — in hierarchical parent/child segments keyed by line of business and state. The PL/I side held the decision trees that walked those segments and computed the premium. The migration target — Ratabase — represents the rules as a platform-neutral decision tree authored independently of where they run, with the rating factors imported as flat reference tables; the cardinality is roughly state × line-of-business × peril, with each policy book held in its own rule namespace so re-rate cycles can target a single state without touching the others.

Key Sequence

1. 01Pick the next rule from the 100+ corpus (typically a single rating algorithm for a single state × line-of-business).
2. 02Identify the actuarial SME who owns that line of business and book a working session — the engineer sits next to the SME, not across a ticket.
3. 03Read the PL/I procedure and the IMS-DB lookup segments together with the SME; express the same decision tree in Ratabase semantics.
4. 04Run both engines side by side on a curated set of representative policies and reconcile the premium output cent-for-cent.
5. 05When the two agree across the full reconciliation set, the actuary signs off and Ratabase is switched on as the source of truth for that rule — the mainframe keeps executing the rules around it.
6. 06If a rating error surfaces in production, run a re-rate cycle across the relevant state policy book — individual cycles returned several-hundred-thousand-dollar customer refunds and acted as the natural correctness check for the new engine.
7. 07Move to the next rule; the rule set lives half on each side for as long as it takes, because the contract surface (given these inputs, return this premium) never moves.

What I owned

• Translated 100+ complex mathematical rating algorithms to system requirements
• Migrated legacy rating engine from Corporate Rating System to Ratabase
• Implemented CEA Earthquake Basic/Choice companion policy rewrites
• Built Wind Mitigation discount systems across FL, LA, and MD
• Managed IMS-DB high-volume database (1M+ transactions/hour)
• Coordinated 114+ engineers across US, India, and Europe
• Used Informatica PowerCenter for ETL; reduced load time by 4 hours via optimization

Trade-offs

• Chose to translate rules side-by-side with actuaries — one rule at a time, signed off cent-for-cent — over waiting for a consolidated spec; the cost is 12–18 months of one senior engineer pairing with SMEs, but the alternative (parallel run on dual-writes) is the worst of both worlds and the project never ships.
• Picked Ratabase as the platform-neutral rules representation over keeping the rules embedded in a new execution runtime; the cost is a real third-party dependency and a learning curve for the actuaries, but the property you get — rules authored, versioned, and tested independent of where they run — is the only property that makes incremental migration possible.
• Let the rule set live half on each engine for years rather than racing a cutover weekend; the cost is operating two engines side by side, but the contract surface never moved and the business never lost a quarter to a freeze.
• Used live re-rate cycles as the correctness forcing function rather than a synthetic reconciliation harness; the cost is that errors are caught in production with real customer money attached, but the feedback signal is unambiguous — refunds in the hundreds of thousands of dollars get everyone's attention.
• Translated 100+ rules procedurally, one SME-pair at a time, rather than attempting an automated PL/I-to-Ratabase converter; the cost is engineer-years of careful work, but the institutional knowledge gets re-created on the way through instead of carried forward as undocumented behavior.

What I'd change today

I'd build the reconciliation harness as a first-class deliverable on day one, not as a side artifact each engineer cobbled together for their working session. Cent-for-cent comparison across a curated policy set is the load-bearing part of this pattern, and we paid an implicit tax every time someone re-built it from scratch. I'd also publish a written contract for what 'switched' means before the first rule was switched — the criteria, the sign-off, the rollback path — instead of letting it accrete as norms. And given today's tooling, I'd seriously evaluate whether LLM-assisted translation of the PL/I procedures (with the same SME pairing as a human-in-the-loop verifier) could compress the 12–18 month tail; not to replace the actuary, but to give the engineer a faster first draft to reason about.

Stack