InformINS is a platform whose customers are carriers, and every one of them wants analytics over their own book. Reporting ran on the same SQL Server estate that carries the transactional platform, which capped how deep the analysis could go and put reporting load next to the system of record.
QyrosCloud designed and built a modern analytical foundation on AWS: nightly change-data-capture from SQL Server into an Amazon S3 data lake, curated datasets loaded into a ClickHouse analytical warehouse, dashboards in Apache Superset, and a semantic layer and data dictionary that define what every measure means. On top of that foundation sits a natural-language querying layer on Amazon Bedrock, so a carrier can ask a question of its own book instead of commissioning a report and waiting for engineering time.
The engagement was validated the way an insurance analytics platform has to be: by reconciling its outputs against InformINS' own benchmark reporting, measure by measure.
What was at stake.
InformINS' reporting ran on SQL Server - the same estate that carries the transactional platform. That arrangement works until the questions get harder. Analytical queries compete with the application for the same resources, deep aggregations across years of premium and loss data are slow, and every new question that falls outside an existing dashboard becomes a report that has to be built.
The result was a queue. A carrier with a question either waited on engineering time or did not get an answer. For a platform whose customers are carriers, that is a product constraint rather than an internal inconvenience.
Anything built to fix it had to be multi-tenant from the first line, because the data belongs to competing carriers and the boundary between them has to be enforced rather than assumed.
“InformINS partnered with QyrosCloud to move insurance analytics off its transactional SQL Server estate onto a purpose-built warehouse on AWS - a nightly change-data-capture pipeline into an Amazon S3 data lake, a ClickHouse analytical warehouse, Apache Superset dashboards, and a semantic layer that makes natural-language querying on Amazon Bedrock possible over a carrier's own book.”
How we solved it.
QyrosCloud built the analytical foundation and the querying layer as one engagement, in the customer's existing AWS account in us-west-2, deployed inside the existing VPC.
The design principle throughout was that a natural-language layer is only as trustworthy as the model underneath it. Most of the work went into the pipeline, the schema and the semantic layer - so that when a question is asked in English, the measure it resolves to has a single agreed definition that has been reconciled against the customer's own benchmark reporting.
An AWS Glue job moves data nightly from the production SQL Server on Amazon EC2 into a newly deployed Amazon S3 data lake, structured as raw, refined and curated layers. Amazon DynamoDB holds the change-data-capture configuration and state as the metadata source of truth, and credentials for both SQL Server and the warehouse are held in AWS Secrets Manager.
Offloading to S3 is what takes analytical load off the transactional estate: queries no longer compete with the application that carriers depend on to run their business.
A ClickHouse cluster was deployed in the existing Amazon VPC, with schemas, partitioning and an index strategy designed for the shape of insurance analytics - aggregations across years of premium and loss data, sliced by coverage, territory, driver class and vehicle type.
Facts and dimensions were modelled to support accurate premium, loss and ratio calculations, and the loaded data was validated for row counts and structure before any dashboard was built on it.
The engagement produced a data dictionary, field and table definitions, source-to-target mappings and decoding documentation for the encoded fields the source system uses.
This is the part that makes the rest defensible. Insurance measures have several defensible definitions - incurred loss, earned versus written premium, whether recoveries are netted - and without a stated definition two dashboards can disagree while both appear correct. The semantic layer fixes which definition is in use, and it is also what a natural-language layer needs in order to resolve a question to the right measure rather than a plausible one.
An Apache Superset cluster was deployed in the same VPC, with role-based access configured and embedding options reviewed so the dashboards can surface inside InformINS' own application.
The initial set covers program-level loss ratio analysis, premium by coverage, losses by ZIP, territory, driver class and vehicle type, claims summary including paid, reserves and legal, and policy-level segmentation - with drill-downs that reconcile correctly to their totals.
The querying layer lets a carrier ask a question of its own book in its own words, rather than commissioning a report. Model inference runs on Amazon Bedrock, so prompt and completion data stays inside the customer's AWS boundary under their own agreement, model choice can change without a new data path, and inference is reachable under AWS IAM rather than a shared API key.
The layer is grounded on the semantic layer built in the same engagement. That ordering is deliberate: a question asked in English has to resolve to a measure with an agreed definition, and a natural-language interface over an undefined schema produces answers that are fluent and wrong.
Warehouse access is through per-carrier scoped database users rather than a shared administrative account - a read-only user per carrier with SELECT on that carrier's database and nothing else. The tenant boundary is a database grant, which is checkable, rather than a code path, which has to be trusted.
Credentials are held in AWS Secrets Manager, and the warehouse and dashboard clusters sit in private subnets within the existing VPC.
“This engagement required us to balance speed with compliance rigor. We deployed infrastructure-as-code from day one, automated evidence collection across the environment, and delivered a production-ready architecture that passed security review on the first attempt.”
The results speak for themselves.
The platform was validated the way an insurance analytics system has to be: not by whether it returns a number, but by whether it returns the same number the customer's own reporting does.
Outputs were reconciled against InformINS' reference Premium and Loss by Coverage report, with dimensional drill-downs checked to confirm they aggregate correctly to their totals.
InformINS provides policy administration, billing and claims software to property and casualty insurance carriers and Managing General Agents across the United States. Its customers depend on the platform both to run their books and to report on them, which makes analytics a product capability rather than an internal tool.
Related stories.
Ready for results like these?
Let's talk about your AWS environment.
Book a discovery call