Building a Marine Underwriting Application on Pega

How Pega’s insurance framework enabled a complex, production-grade Marine UW platform — built for India, relevant globally.

The Business Problem

Marine insurance underwriting is one of the most complex lines in P&C. Every client has a different commodity mix, transit structure, and risk appetite. Legacy systems, built for a different era, were never designed for this kind of flexibility.

The insurer we worked with was running on a mainframe platform used purely for data capture — no business logic, no workflow, no SLA tracking. Pricing was done manually on spreadsheets. Quotes were assembled in Word and Excel documents outside any system of record. There was no audit trail and no way to enforce underwriting guidelines consistently across the team.

At the product level, there was no modular configuration. Defining a product hierarchy — Risk → Coverages → Benefits → Pricing — was not possible. Every change meant manual intervention. For a line as dynamic as Marine, this was a serious operational constraint.

Why Pega

Pega was selected because it brought two purpose-built insurance frameworks — Pega Underwriting for Insurance and Pega Product Builder — providing a structured, insurance-aware foundation and significantly reducing the need to build core constructs from scratch.

Few Key platform capabilities made it the right fit:

Quick product launch — New Marine products and channel-specific variants configured and deployed by business users — no development cycles needed.

Regulatory agility — Product terms, clauses, and limits updated through configuration. Business users manage most IRDAI-driven changes independently after basic platform training.

Multi-channel delivery — Pega’s architecture allows the same business logic to be delivered across multiple channels — internal portals, customer-facing websites, and aggregator APIs — without rebuilding rules for each channel. More on this below.

Role-based dashboards — Differentiated views for underwriters, operations, and management replaced fragmented offline reporting.

Layered rule design — Shared business rules defined once at a common layer and reused across all products and LOBs — no duplication, no inconsistency.

How We Built It

Team and Discovery

The team combined insurance domain depth with Pega expertise: a Lead System Architect, Senior System Architect, Insurance SMEs acting as BAs, and a QA team. Discovery came first — structured workshops with underwriters and SMEs to map the As-Is process, followed by gap analysis and To-Be design. The goal was a Pan-India deployment serving Underwriting, Operations, Reinsurance, Agents, and Brokers from day one.

Application Architecture

The application was structured in four layers, each building on the one below:

Base — Pega’s insurance framework — providing core underwriting constructs out of the box.

Organisation layer — Capabilities shared across all LOBs: Client Management, Agent and Broker Management, Reinsurance and Co-insurance rules, and the Receipting module. Built once, inherited by every product.

Marine layer — All Marine-specific logic: cargo and vessel accumulation, PML calculation, certificate generation, SI-based calculations, and geographical accumulation tracking.

Product layer — Three Marine products configured using Pega Product Builder — Marine Open Policy (MOP), Sales Turnover Policy (STOP), and Specific Voyage Policy — each with channel-specific variants (Broker, Bancassurance) and modular setup: Risk → Coverages → Discounts → Pricing → Exclusions → Clauses. New product versions via drag-and-drop, no development needed.

Key UW Features and Business Benefits

The real value was in the underwriting process itself. Below are the features built and how they directly benefited underwriters and the business.

Flexible Commodity and Sum Insured Capture

Marine clients rarely have simple, uniform risks. Underwriters needed to capture each risk the way the client actually structures it. We built three SI modes, all available within a single proposal:

Combined SI — one sum insured across all commodities

Individual SI — separate values per commodity

Leg-wise SI — distinct values for Domestic, Import, and Export legs independently

Business benefit: UWs could meet client requirements precisely, reduce back-and-forth, and issue competitive quotes faster — without stepping outside system-enforced underwriting parameters.

Dynamic Pricing with Loss Ratio Intelligence

Three rating methods gave underwriters the right tool for each risk:

Highest Rate Method — single rate applied across all commodities — used when no prior claim history is available.

Individual Commodity Rate Method — separate rates per commodity, fetched from the rate master.

Claim Experience Rate Method — when the client provides claim history, the system calculates an As-If Claim Ratio and As-If Rate based on actual loss experience. This gives a more accurate, fair rate for clients with good claims records.

Beyond rate selection, the system auto-calculated a minimum desired base rate and premium using three years of loss ratio data — a data-backed starting point for every negotiation. Underwriters with the right privilege level could adjust the rate or premium within defined bounds, giving them a genuine but governed negotiation lever.

Business benefit: Pricing became data-driven rather than intuitive. UWs spent less time on calculations and more time on client conversations — while staying fully IRDAI-compliant by design.

Dynamic Clause and Cover Terms Configuration

Underwriters could capture multiple clauses and cover terms — including standard Marine clauses such as ITC and ICC (A, B, C) — against a proposal. These clauses were not rigidly linked to specific commodity types. Instead, a backend master mapped each clause to commodity type, transit type (Import, Export, Domestic), applicable rates, and packaging type. Based on the underwriter’s selections, the relevant clauses populated dynamically.

Business benefit: Clause capture became structured and accurate. UWs no longer had to remember or manually apply which clauses applied to which risk — the system guided them based on what they had already selected.

Deviation Detection and Escalation Workflows

Not all risks fall neatly within standard underwriting guidelines. We built deviation and escalation rules that automatically flagged when the risk or coverage configuration strayed outside UW parameters. The underwriter could then either correct the data or escalate — triggering a structured routing and approval workflow. Full audit history was maintained at every step.

Business benefit: Risk decisions were no longer dependent on individual knowledge or informal checks. Deviations were visible, traceable, and handled through a governed process — reducing both errors and compliance exposure.

Reinsurance Process Automation

The RI process had previously been entirely manual and offline. We automated retention capacity calculation (PBL/PLL-based for MOP and STOP), and the full RI allocation across Obligatory treaty, Facultative, and retention shares. Every quote went through a structured RI team review and approval workflow before reaching the customer.

Business benefit: UWs could assess RI implications in real time, make informed decisions on co-insurance, and move quotes forward faster — with full RI governance maintained throughout.

Co-insurance Leader/Follower model

Beyond reinsurance, we also built Co-insurance functionality that works in tandem with the RI module. Once the insurer’s retention capacity was calculated, the system determined whether the insurer would take the role of Leader or Follower on a given risk. As Leader, the insurer drives the terms and coordinates other co-insurers. As Follower, it participates at a defined share under another insurer’s lead. Each co-insurer’s share was configured within the same proposal, giving underwriters full visibility of how the total risk was distributed across all parties before the quote was released.

This Leader/Follower model, combined with automated RI allocation, meant that even large or complex risks could be structured, shared, and governed entirely within the platform — replacing a process that had previously relied on offline negotiations and manual documentation.

Business benefit: UWs could assess retention, RI allocation, and co-insurance participation in one place, in real time. Large risks that previously required multiple offline conversations could now be structured and approved within a single governed workflow.

Multi-Channel Delivery — Including Customer Self-Service

The application served multiple user types through dedicated interfaces, all running on the same underlying business rules:

Internal UW Portal — for underwriters, agents, TPAs, and Banca partners

Customer Self-Service Portal — end customers could generate consignment certificates and declare shipments directly, without routing through operations

Insurer Website via Pega Web Mashup — customers could initiate and submit quotes directly from the insurer’s own website. Pega Web Mashup embedded the Pega UI seamlessly within the insurer’s web presence — no separate application, no duplicated business logic. The same underwriting rules, validations, and workflows applied regardless of which channel the quote came from.

Business benefit: The insurer could serve customers across every channel — agent, direct, aggregator, bancassurance — without maintaining separate rule sets for each. New channels could be added without reworking the core application.

Where AI Fits: Risk Classification at Intake

Everything described so far is deterministic. Masters, rules, calculations, workflows, approvals. That was a deliberate choice, and it is also what makes the next step possible.

Marine underwriting has a bottleneck that sits before underwriting begins. A broker submission arrives as an email with attachments. The commodity schedule is in a spreadsheet, the transit details are in the body of the mail, the claim history is in a separate file, and there is often a copy of the expiring policy somewhere in the thread. Before an underwriter makes a single judgment call, someone has to read all of it, work out what is actually being asked for, and get it into the system in a shape the platform can use. On a large commercial account, that is hours of preparation for minutes of underwriting.

This is where we are now building an AI agent on top of the platform.

What the AI does

Reads the submission. Email body and attachments together, including the formats brokers actually send rather than the formats we would prefer.

Works out the structure of the risk. Which commodities, which transit legs, whether the client is asking for a combined sum insured, individual values per commodity, or leg-wise values across domestic, import and export.

Classifies the risk. Commodity type, packaging, transit mode and route, mapped against the same masters the platform already uses for clause and rate selection.

Prepares the proposal. Populates the fields it can evidence, and writes a short summary of the risk the underwriter can read in under a minute.

Says what is missing. Flags the gaps that would stall the quote later, so the broker gets one clear list of questions instead of three rounds of email.

Business benefit: the underwriter starts the day with a risk that is already read, structured and summarised. Preparation time moves from the underwriter to the platform, and the first response back to the broker gets faster without anyone underwriting faster.

What the AI does not do

It does not price. It does not select clauses. It does not approve a deviation and it does not bind. Those decisions stay where the platform already puts them, with the underwriter and the approval chain, governed by the rules described earlier in this paper.

That boundary is not a limitation we are working around. It is the design. The agent handles the reading and the preparation, which is the part that consumes the most time and the least judgment. The judgment stays human, and it stays inside a workflow that already records who decided what and why.

Why the platform underneath matters

An AI doing this work with nothing beneath it has to do everything itself. It has to hold the product structure, remember which clauses apply to which commodity and transit type, reproduce the rating logic, and keep track of where it is in a multi-step process. All of that becomes model work, and model work is billed by the token.

We ran the same agent three ways and measured what each one consumed. The version built on Pega used 47% fewer tokens than the equivalent scratch build, and in the scratch build 72% of the tokens went on orchestration rather than on the actual task. The reason is visible in this application. The clause masters, the rate methods, the SI structures, the deviation rules and the RI allocation already exist as configuration. The AI does not need to know any of it. It reads, structures, classifies and hands over.

That is the practical case for putting AI on top of a platform rather than beside one. It is not only a governance argument. It is a running cost argument, and the gap widens with every account the agent processes.

Governance is inherited, not added

Because the AI runs as a step inside the case, every extraction, every classification and every hand-off to the underwriter is recorded the same way the deviation and escalation history is recorded. There is no separate AI audit log to build and no second system to reconcile at review time.

For any insurer working under an AI governance regime, and most now are, this is the difference between demonstrating control and reconstructing it. The same principle that applied to IRDAI compliance in the original build applies here: design it in, do not patch it on.

Where this stands

The marine platform described in this paper is live and has been in daily production use for over two years. The intake agent is a current build with a commercial lines insurer, running on a twelve-week single-agent model. We are being deliberate about the sequence. One agent, in production, doing real work, before the second one starts.

The second one prices the risk, assembles quote options within the bounds the platform already enforces, and gives the underwriter a way to send them back to the broker. Same pattern, same platform, one step further along the process.

Lessons Learned

Marine is complex — but buildable. — Pega does not make hard things easy. It gives you the right tools to build hard things properly. The features here — leg-wise SI, dynamic pricing, As-If rating, automated RI, deviation workflows — are not trivial. The platform made them manageable.

Discovery quality determines delivery quality. — The right business vision, accurate gap identification by BAs and SMEs, and a clear ROI case early are not soft prerequisites. They are the foundation. Time invested in discovery pays back many times over in delivery.

Compliance by design, not by patch. — Embedding IRDAI rules into pricing and product configuration from day one avoided significant rework later. Compliance should be a design constraint, not an afterthought.

Involve underwriters early. — UWs are experienced professionals with strong instincts. Bringing them into design — not just UAT — produced better features and smoother adoption.

User feedback is the real benchmark. — After two years of live use, business users confirmed this application had no comparable equivalent in the Indian market — and felt it could serve global Marine use cases. That kind of endorsement means more than any go-live milestone.

Conclusion

Marine underwriting is not a problem that yields to generic solutions. It needs a platform that handles structured complexity, supports underwriter judgment, and adapts as regulations and markets evolve. This engagement showed that Pega, with the right architecture and domain understanding, can meet that bar.

What we built was not a pilot. It was a production system — live, at scale, serving underwriters, operations, reinsurance, agents, and customers across one of India’s more demanding commercial insurance environments. It has earned its credibility through years of real use, not just a successful go-live.

For insurance technology leaders: the platform is ready. The harder question is whether your organisation is ready — with the right vision, the right SME involvement, and the discipline to invest in discovery before design. Get those right, and a system like this is well within reach.

Marine is a template. The patterns here — modular products, flexible risk capture, dynamic pricing, automated RI, deviation governance — apply equally to Fire, Liability, and Engineering. This is a proof point for complex commercial lines, not just Marine.

For Pega practitioners: Marine UW is a genuinely interesting problem to solve. If this paper has raised questions about specific design decisions, architecture choices, or the challenges we navigated — I would welcome that conversation.