Policy Administration System
Issuance, endorsements, renewals, and cancellations.
Integration is the least visible work in insurance technology and the most load-bearing.
Almost every project on this site depends on it, and most stalled projects stalled here.
Connect systems you don't control and can't change
Stop paying people to move data between screens
Get one version of the numbers instead of three
Modernize around the core rather than replacing it
Products + Services
What we build, implement, and support in this category.
Issuance, endorsements, renewals, and cancellations.
Policy, billing, and claims as one connected solution.
The unified data foundation everything else reports from.
Connecting core systems, data platforms, and point solutions, including partners with no formal API.
Moving off legacy cores to modern architecture, in phases rather than all at once.
Extracting, cleansing, mapping, and migrating policy and claims data.
Standardizing, de-duplicating, and enriching datasets.
Roadmaps, target operating model, and technology strategy.
Helping you choose between platforms, without a stake in the answer.
Assessing and hardening systems, and testing defenses.
Preparing for audits and attestations.
Use Cases
These are places we do real work connecting an insurance operation. Each one has been built for an insurer already, and most engagements start in one and expand from there.
Carrier and partner connectivity
Connecting to policy administration, billing, claims, rating, and reporting systems belonging to other people. Portals with no API, file drops on a schedule, formats that change without notice. We’ve built more than 300 of these, which is mostly a way of saying we’ve met most of the ways it goes wrong.
The layer between your core and everything else
API and microservices architecture that lets intake, portals, analytics, and third-party tools reach core data without anyone touching the core itself. The project that makes the other projects possible.
Data pipelines and the warehouse underneath
Ingestion, validation, transformation, and the warehouse or lake it all lands in, plus the reporting layer that makes it usable. The exception handling matters more than the pipeline: clean data is easy, and clean data is not what arrives.
Legacy modernization without the rip and replace
Moving weight off a core system one function at a time, so the day you retire it is uneventful rather than terrifying. Sometimes the destination is a new platform. Often it’s a modern layer around a system that still does its job.
Data migration and conversion
Extracting, cleansing, mapping, and moving policy and claims data during a platform change or a consolidation. Usually the part of a migration that runs long, and usually because nobody scoped the data quality work honestly at the start.
Post-acquisition consolidation
Two or more operations running different systems, with a mandate to look like one company. Deciding what merges, what integrates, and what stays where it is, then building accordingly.
who we serve
A core system that makes every change a project, surrounded by point solutions nobody planned together. The work usually starts by building the layer that lets everything else reach the data.
Paktolus for Carriers →Every capacity partner wants data in their own format, on their own schedule. One source of truth that produces all of them is worth more than any single integration.
Paktolus for MGAs →A core older than most of the team, a small IT group, and no appetite for a multi-year replacement. Phased modernization around what works is usually the right answer here.
Paktolus for Mutuals →An agency management system that doesn’t talk to carrier portals or raters, often across multiple offices and acquired agencies on different stacks.
Paktolus for Agencies →Placing across dozens of markets on dozens of systems, most of which you have no influence over.
Paktolus for Wholesalers →Cession data arriving from every cedent in a different shape, with reconciliation absorbing the difference. Ingestion and normalization before anything else can be built.
Paktolus for Reinsurers →Results
Unifying seventeen systems for a global insurance exchange
One of the largest insurance exchanges in the world was running on seventeen distinct systems, a mix of third-party products and internal builds, with little integration between them. The consequences compounded: duplicate data entry, reports that didn't reconcile, and production processes that ran late because information had to be assembled by hand first. We designed and engineered a unified platform combining data from all of them.
70%
efficiency gains
200+
insurance carriers integrated
6,000+
product variations supported
7.5M
active users
Carrier data ingestion for a reinsurance market intermediary
A business providing MGAs, program administrators, and InsurTechs with access to the reinsurance market was struggling to ingest and validate carrier data at volume. Formats were inconsistent, fields were missing, and the ETL process was a bottleneck. We built a Python-based pipeline that validates and ingests monthly data from more than 25 sources.
25+
data sources processed within minutes
99%
reduction in business reporting time, from eight hours to seconds
Extending a carrier's distribution reach
A fast-growing homeowners insurer wanted to expand across US markets through third-party carriers, partners, and agent networks, while its own engineers stayed focused on underwriting and actuarial work. We built and ran the distribution and aggregation platform, along with the business intelligence layer on top of it.
20%
increase in top line revenue
100%
market coverage
90%
reduction in level one support tickets
Our approach
Some clients come to us with a defined project. Others come with a problem and no idea what the shape of the solution is. Either way, the answer to that question is what we build against. We plug in wherever you need us, from a single initiative to a full-scale program, and we stay as long as it’s useful.
CEO and Co-Founder
Discovery, architecture assessment, build-versus-buy analysis, and scoping. Some engagements stop here, and that's a legitimate outcome. You leave with a decision you can defend and a plan someone can actually execute.
Custom development or implementation and configuration of what you already run. Phased, specified, and measured against the outcome you chose. When it goes live, your team knows how to run it.
Ongoing support, enhancement, and managed services, for what we built or for what you were running before we met.
We’re technology and vendor agnostic. Sometimes the right answer is custom-built around exactly how your team works. Sometimes it’s optimizing the platform you already run on. We don’t lead with a preferred stack, we lead with your goals.
Common Questions
Yes, and it is a large share of what we do. Carrier portals, partner systems, and older platforms frequently have no formal API, and waiting for one is not a plan. We work with whatever the system actually offers: file exchange on a schedule, screen-level automation, database-level access where it is permitted, and API development where we can build one. More than 300 carrier integrations means most of the awkward cases are ones we have met before.
Usually not, and we would often argue against it. Most of what insurers want from a new core can be delivered around the one they have: intake, rating, portals, reporting, and the data flow between them. Phased modernization moves weight off the core one function at a time, which lowers the risk and lets results fund the next phase. When replacement genuinely is the right answer we implement and migrate too, but that should be a conclusion rather than a starting assumption.
Longer than the plan says, if the data quality work was not scoped honestly. The extract, map, and load is the predictable part. What runs long is the exceptions: records that do not conform, fields that mean different things in different systems, and history nobody can fully explain. We scope that work explicitly rather than discovering it, which makes the timeline less exciting and more accurate.
We work across the tooling our clients already run rather than a preferred stack. On integration engagements that commonly includes Guidewire and Duck Creek, agency management and rating systems, Snowflake, Databricks and BigQuery, cloud platforms including AWS, Azure, and Google Cloud, and older or homegrown systems that are more common in the mid-market than vendor marketing suggests. That is a sample rather than a list of preferences.
Yes, and we have no stake in the answer. We are not a reseller and we hold no vendor partnerships that pay us to recommend one product over another. Vendor selection advisory is a service we deliver on its own, and some engagements stop there, with a decision you can defend and no build attached.
They get built to the specification rather than to what the partner actually sends. The spec says the file arrives on the first of the month with twelve fields populated. Production sends it on the third with two fields blank and a new column nobody mentioned. Integrations that assume the happy path push everything else into an exception queue, and the exception queue becomes the new manual process. We design for what actually arrives.
Twenty minutes, a candid conversation. If we’re not the right fit, we’ll say so.