Modern Core Insurance Platform Development: Policy Admin, Billing, Claims, and Distribution

As Head of Tech and Client Success at Acquaint Softtech, a software development and staff augmentation partner serving carriers, MGAs, brokers, and InsurTech startups across the US, UK, Australia, and the UAE, I have sat in enough architecture reviews to spot the error before anyone opens a diagram. The error is consistent: the team describes their platform as four systems, a policy administration system (PAS), a billing engine, a claims platform, and a distribution portal, and then spends the next 40 minutes explaining the integration problems between them.

Those integration problems are not integration problems. They are the consequence of building four systems when the goal required one core insurance platform, policy, admin, billing, and claims distribution model.  

A mid-term endorsement triggers a premium recalculation in the PAS that does not propagate to the billing engine before the next instalment date. A broker checks the distribution portal for the current policy state and sees a version that is two events behind. Every one of these is a design error, not an integration task.

---

This article defines what a core insurance platform actually is: one shared data model, one event bus, four owned modules, and explains how to build it correctly. For a broader InsurTech engineering context, the master guide to InsurTech software development in 2026 covers the full landscape. 

For the specific engagement model used on core platform builds, software product development services for insurance platforms describe how Acquaint Softtech structures these engagements.

Problem → Agitation → Solution

Problem: Carriers and MGAs scope their platform as four separate procurement decisions with four separate vendors, delivery timelines, and data models.

Agitation: At the first renewal cycle, they discover that a mid-term endorsement crossing four systems is a compliance gap, a billing error, and a broker communication failure simultaneously, and fixing it requires rebuilding the integration layer at a cost that exceeds the original project budgets.

Solution: Design the platform as one shared data model and one event bus from the start. The four modules own their domains. They share the record. Every state change is an event, not a handoff.

The Anatomy of a Core Insurance Platform

The Single Policy Record

Every module reads and writes the same policy object. The PAS creates it at bind. The billing engine reads its premium terms to generate the payment schedule. The claims platform reads its coverage details at first notice of loss (FNOL). The distribution portal reads its current state to display to the broker. There is no copy of the policy in the billing database. There is no copy in the claims database. There is one versioned policy record with a complete change history.

Carriers writing more than 50,000 policies a year on four-system architectures typically spend 150 to 350 hours per month on manual policy reconciliation across those copies. Acquaint Softtech's database optimization services for high-volume policy data are specifically designed around this single-record pattern, because the schema design determines whether reconciliation is an engineering problem or a daily operations task.

The Shared Event Bus: The Audit Trail as Compliance Spine, The Product Configuration Layer

Above the four modules sits a product configuration layer that defines product structures, rating tables, coverage options, and form sets per line of business without requiring engineering changes. Adding a new commercial lines product, adjusting a rating factor, or updating a state-specific form should be a configuration operation, not a deployment. 

This is the structural difference between a platform and a bespoke system and it is the primary reason carriers on custom platforms can launch new products faster than carriers on commercial platforms stuck in configuration queues. The software product engineering services for a policy administration system at Acquaint Softtech are built around this configuration layer as the first architectural deliverable.

Module Ownership Map: What Each One Owns

Module 1 — Policy Administration System (PAS) OWNS: Quote capture, rating engine execution, bind and policy issuance, form generation, mid-term endorsements with premium recalculation, renewal workflow, cancellation and reinstatement, regulatory filing and compliance reporting per state or jurisdiction. DOES NOT OWN: Billing (creates the premium obligation, passes it to billing as an event), Claims (validates coverage at FNOL, passes claim to claims module), Distribution (receives the bound quote from distribution, issues the policy record).

Module 2 — Billing Engine OWNS: Premium schedule creation based on payment plan and instalment structure, invoice generation by channel (email, portal, agent billing), payment collection via ACH, card, EFT, debit, delinquency management with grace periods and cancellation triggers, return premium calculation on cancellation or endorsement, commission calculation and payment to agents, brokers, and MGAs. DOES NOT OWN: Policy terms (reads from PAS), Claims payments (claims module generates settlement amount and instructs billing to disburse), Product configuration (reads coverage and premium rules from PAS configuration layer).

Module 3 — Claims Management Platform OWNS: FNOL intake by channel (portal, mobile FNOL app, phone, EDI feed from TPA), coverage verification against the current PAS policy record, reserve setting and actuarial reporting, adjuster assignment, document management with OCR (Optical Character Recognition), settlement calculation and disbursement instruction to the billing engine, subrogation and salvage accounting, and reinsurance recovery reporting. DOES NOT OWN: Payment disbursement (instructs billing), Policy issuance (reads coverage from PAS), Agent communication (handled by distribution module).

Module 4 — Distribution and Agent Portal OWNS: Comparative quoting for agents and brokers, agent and broker onboarding with licence verification, policy submission and bind workflow with straight-through processing (STP) for qualifying risks, policy servicing (certificates of insurance, endorsement requests, cancellation requests), commission statement and payment portal, embedded insurance API for digital distribution partners. DOES NOT OWN: Policy issuance (submits to PAS), Premium collection (passes payment instructions to the billing engine), Claims adjudication (provides agents and policyholders with claim status from the claims module).

Build vs Buy: Custom Core Platform vs Guidewire, Duck Creek, and Majesco

Dimension	Off-the-Shelf Platform	Custom Core Platform (Acquaint Softtech)
Time to first live policy	12 to 24 months for a standard P&C implementation	6 to 9 months for an MVP covering one line of business
Annual licensing cost	$500,000 to $2,000,000+ scaled to written premium volume	No licensing fee — fixed monthly team rate only
Rating engine flexibility	Configurable within platform limits; proprietary actuarial models require workarounds	Full custom rating logic, actuarial model integration, bureau feed direct connection
ISO and ACORD content library	Pre-built ISO forms, ACORD XML integrations, state-specific filing templates	Custom build required; bureau content licensed and integrated to client specification
New line of business speed	Dependent on the platform release cadence and vendor configuration queue	Configuration layer addition; no code deployment required for standard line variants
Codebase and IP ownership	Vendor-owned; client accesses via API and configuration tooling	Client owns 100% of the source code, schema, infrastructure, and data from day one
5-year total cost of ownership	$3,000,000 to $10,000,000+, including licence, implementation, and upgrades	$1,500,000 to $4,000,000, including build, team, hosting, and maintenance
Best fit scenario	Standard P&C lines, large enterprise carrier, existing in-house technology team, budget for 18+ month implementation	Non-standard products, API-first distribution, proprietary rating, codebase ownership requirement, MGA or startup-scale carrier

The Comparison Most Founders Get Wrong

Most carriers compare the off-the-shelf platform's marketing timeline ('go live in 12 months') against the custom build's actual scoped timeline. The correct comparison is a scoped implementation of the commercial platform for your specific product lines against a scoped build for your specific product lines. Standard P&C commercial lines on Guidewire or Duck Creek can go live in 12 to 18 months.

Non-standard specialty lines, embedded insurance products, or parametric triggers on the same platforms typically take 18 to 30 months of configuration and customization, at a cost that often exceeds the custom build. The decision must be made on the specific carrier's product structure, not on the vendor's average implementation timeline.

Phase-by-Phase Delivery: How the Build Runs

A core insurance platform built at Acquaint Softtech follows a structured delivery sequence. The shared foundation, data model, event bus, audit trail, and configuration layer are built before any module begins. This is the most important structural decision of the engagement. Modules built before the foundation is established become integration problems, not contributions to a platform. For carriers scoping the first sprint, our product discovery workshop for a PAS build is the specific engagement format that produces the event catalogue and module map before any code is written.

1. Discovery and Product-Line Scoping (Weeks 1–3)

The Acquaint team interviews the carrier's underwriting, billing, claims, and distribution leads to map current workflows and produce the architectural deliverables: the policy record data model, the event catalogue listing all state-change events, the module ownership map, and the tech stack recommendation. The client approves the data model and event catalogue before engineering begins. No code is written in this phase.

2. Shared Foundation Build (Weeks 4–8)

The database schema for the policy record is built and deployed in staging. The event bus is configured. The authentication and authorization layer is established with role-based access control (RBAC) for carrier admins, underwriters, adjusters, billing staff, and agents. The audit trail service is deployed. The product configuration layer is established with a test product for initial validation. No business features are visible at the end of this phase. The foundation is the deliverable.

3. PAS and Distribution Module (Weeks 9–22)

The PAS and distribution modules are built in parallel because they share the highest interaction volume: a quote captured in distribution triggers rating in the PAS, which returns a bindable quote to distribution. The rating engine is the most complex deliverable in this phase. The distribution portal is built as a React frontend consuming the PAS API, with separate interfaces for agents (desktop) and policyholders (mobile). For the policyholder mobile layer, the team includes React Native developers alongside the web build.

4. Billing Engine (Weeks 18–26)

Built after the PAS because it depends on the premium obligation events the PAS generates. Deliverables: premium schedule creation, instalment logic, payment gateway integrations (Stripe for card payments, Plaid for ACH, or direct bank integrations for larger carriers), commission ledger, delinquency workflow with grace periods and cancellation triggers, and return premium calculation. Reinsurance bordereaux reporting is configured in this phase for carriers with treaty reinsurance programmes.

5. Claims Management Platform (Weeks 22–34)

Built last because it has the most third-party integration surface: ISO ClaimSearch, LexisNexis CLUE (Comprehensive Loss Underwriting Exchange), repair network APIs, medical bill review services, and TPA (Third-Party Administrator) EDI feeds. FNOL intake, coverage verification, reserve setting, adjuster assignment, OCR document management, and settlement instruction to billing are the core deliverables. AI claims triage, severity classification at FNOL, and fraud scoring are scoped in this phase for carriers with policy volume sufficient to train or fine-tune models.

6. Regulatory Review and End-to-End Testing (Weeks 32–38)

End-to-end testing runs a complete policy lifecycle: quote, bind, issue, endorse, bill, FNOL, adjudicate, settle, renew. All audit events are verified against the shared audit trail. The NAIC market conduct examination simulation is executed. ACORD (Association for Cooperative Operations Research and Development) form output is validated. State filing documents are reviewed against the configuration layer's regulatory content. The engagement closes with source code transfer, documentation walkthrough, and a 30-day Q&A window.

For the backend services that power the event bus and module APIs, Acquaint Softtech's scalable backend development services for a policy administration system cover the Node.js and Laravel API layers used in most core platform builds. For carriers or MGAs who need AI-powered features within the claims or underwriting modules, our AI development services for underwriting and claims triage are integrated into the delivery team from Phase 3 onwards.

2026 Cost Reference: What a Core Insurance Platform Costs to Build

Engagement Tier	Scope	Timeline	Investment (USD)	Equivalent In-House Team (USD/yr)
Tier 1: Carrier MVP	PAS + billing + distribution for one P&C line of business. Claims deferred to Phase 2.	6 to 9 months	$280,000 to $480,000	$650,000 to $1,000,000/yr
Tier 2: Mid-Market Carrier	Full four-module platform for three lines of business with ISO rating integration and agent portal.	10 to 16 months	$580,000 to $1,100,000	$1,300,000 to $2,200,000/yr
Tier 3: Enterprise Carrier / MGA	Full platform with multi-state filing, reinsurance bordereaux, AI claims triage, embedded insurance API, and white-label distribution.	16 to 28 months	$1,200,000 to $2,800,000	$3,000,000 to $5,500,000/yr

What the Monthly Rate Includes at Acquaint Softtech

• Dedicated engineers with InsurTech domain experience, not generalists rotated across accounts.

• Project manager and QA engineer included in every engagement, not billed separately as add-ons.

• DevOps and cloud infrastructure setup on AWS, Azure, or GCP, included in the first month.

• ACORD form integration and ISO rating table setup included in scope, not billed as separately negotiated extras.

• Shared audit trail service and compliance reporting templates built into the foundation from sprint one, not retrofitted at go-live.

• Source code, Infrastructure as Code, architecture documentation, and data dictionary handed over at engagement closure with no retention clause and no re-licensing requirement.

• Developer replacement guarantee at no additional cost or disruption if a developer does not meet expectations. Replacement should not require significant client effort to coordinate.

The rate the client pays is the rate. No additional employer overhead on top. No visa or relocation cost. Based on Acquaint Softtech's delivery operations across 1,300+ projects, clients typically save 40% versus equivalent US or UK in-house teams at senior-level quality. Deployment of the first developer typically happens within 48 hours of the engagement starting.

Five Questions That Tell You Whether to Build or Buy

Is Your Rating Logic Proprietary or Standard

Yes → Build custom. Off-the-shelf platforms cannot accommodate proprietary rating logic without expensive workarounds that the vendor does not support.

No → Standard factor-based rating for personal or commercial lines is well-served by Guidewire or Duck Creek configuration.

Do You Need Full Codebase and IP Ownership?

Codebase ownership means the source code, schema, and infrastructure are your property, not licensed from a vendor. This matters for white-label distribution, regulatory examinations requiring source code review, M&A due diligence, or any partnership where a carrier counterpart needs to inspect the system. For carriers who need full ownership, our dedicated software development team for an InsurTech startup is the engagement structure that delivers 100% IP transfer at every sprint.

Yes → Build custom. Off-the-shelf platforms provide API access without codebase ownership.

No → API access without ownership is sufficient for most standard carrier operations on commercial platforms.

Is Your Distribution Model API-First Rather Than Agent-Portal-First?

Embedded insurance, parametric triggers, on-demand daily policies, and API-first distribution to fintech partners require distribution architectures that standard agent portals do not provide. If your route to market is a developer API consumed by a travel platform, an e-commerce checkout, or a fintech partner, the distribution module needs to be an API product. Acquaint Softtech's product development services for insurance platforms include the API-first distribution architecture as a first-class deliverable.

Yes → Build custom. Commercial platform distribution modules are agent-portal-centric and require significant extension to serve API-first channels.

No → Standard agent and broker distribution via portal is well-served by commercial platform distribution modules.

Do You Write More Than One Non-Standard Line of Business?

Yes → A custom configuration layer built around your specific product catalogue provides faster time to market for new products than a commercial platform's configuration queue.

No → Standard multi-line carriers on Guidewire or Duck Creek add new products within the platform release cadence, which is typically faster than commissioning a new custom build.

Is Your Annual Policy Volume Above 50,000 and Growing?

Yes (or on trajectory to 50K) → Custom build is the more economical path at a 5-year horizon when licensing scales to premium volume.

No (below 10K policies, standard lines) → Commercial platform wins on total cost of ownership at sub-10K volume with standard product lines.

For carriers or MGAs who need a senior technology leader to guide these architecture decisions without a full-time hire, our virtual CTO services for an InsurTech startup provide that function at a fraction of the in-house cost. 

For teams that need to hire individual specialists rather than a full team, hiring Laravel developers for an InsurTech SaaS and hiring Python developers for actuarial and rating models are the two most common starting points for core platform builds at Acquaint Softtech.

The Four Misconceptions Founders Carry Into Core Platform Projects

Misconception 1: A PAS Is a Core Platform Reality: A PAS (Policy Administration System) is one module of a core platform. It owns quote, bind, issue, endorse, renew, and cancel. It does not own billing, claims, or distribution. Carriers that build a PAS and call it their platform discover the gap when the first billing cycle runs, or the first FNOL (First Notice of Loss) arrives. A PAS is the central module, but the platform requires all four modules sharing one data model to function as an operational insurance engine.

Misconception 2: Off-the-Shelf Platforms Always Launch Faster Reality: A full Guidewire or Duck Creek implementation for a standard P&C carrier takes 12 to 24 months. A custom core platform MVP for one line of business at Acquaint Softtech takes 6 to 9 months. Off-the-shelf is faster when the carrier's product lines and workflows conform exactly to the platform's configuration model. When they do not, the customization required inside the platform often takes longer than a ground-up custom build — and the customization code is not transferable when the vendor releases the next major version.

Misconception 3: Custom Platforms Cannot Handle Regulatory Compliance Reality: Regulatory compliance in a custom core platform is a build decision, not a platform limitation. NAIC market conduct compliance, ACORD form integration, ISO ClaimSearch integration, state filing report generation, Solvency II data export, GDPR (General Data Protection Regulation) data handling, and HIPAA (Health Insurance Portability and Accountability Act) for health lines are all engineering deliverables built into the shared audit trail and configuration layer from sprint one at Acquaint Softtech. The difference from an off-the-shelf platform is that the regulatory content is commissioned, not pre-built. The result is a compliance posture fitted exactly to the carrier's regulated markets.

Misconception 4: Claims Can Be Deferred Until After Launch Reality: Claims are deferred in many initial builds because it is the most complex module. The consequence is a carrier that launches with PAS, billing, and distribution that connect to a manual claims process. Every FNOL that goes through a spreadsheet or an emailed PDF generates an audit trail gap. Regulators, reinsurers, and institutional investors all review claims handling in due diligence. Deferring claims beyond the first renewal cycle creates a compliance liability and a reinsurance risk. The module should be scoped in the build even if the full feature set is phased across two delivery windows.

 The compliance patterns described above, shared audit trail, access control, event-driven change history, are the same Acquaint Softtech built into the regulated operations platform for ASQS (Aviation Safety Quality Software), a compliance-intensive platform for safety-critical operations. The full architecture reference is documented in the aviation safety software development case study, which is the strongest available proxy for the audit trail and access-control patterns used in NAIC market conduct and Solvency II reporting contexts. 

For carriers or MGAs who want to modernize a legacy PAS or migrate from a mainframe to a cloud-native core platform without a full replacement, our software modernization services for a legacy PAS cover the phased migration approach. 

For post-launch coverage of insurance platform maintenance and regulatory content updates, our application maintenance services company for InsurTech platforms are structured for this workload.

Frequently Asked Questions