01
Reconciled claims extract
One line of business balanced to the ledger and stored by valuation date.
Insurtech / Actuarial Software
Actuarial software that gives your models reconciled data
Reserving often starts with days of rebuilding extracts that never quite match the ledger. Agnotic Technologies builds the software around the actuarial team: one reconciled data set, triangles on demand and a record of every model run. Your actuaries keep their models and their judgment.
Data mart
Reconciled to the ledger
Triangles
Paid, incurred and counts
Run log
Inputs through sign-off
Trusted by global innovators
Industry Overview
What is actuarial software?
Actuarial software is the data and workflow layer an insurer's actuaries rely on for reserving, experience studies and financial reporting. Agnotic Technologies builds it as a services engagement: a claims and exposure data mart reconciled to the general ledger, triangle builders, study pipelines and a model run registry, while the actuaries keep their own models.
Industry Challenges
Where does actuarial work lose time before modelling starts?
In most teams we talk to, the models are sound. The hours go into the data and the paper trail around them.
Claims and premium extracts are pulled by hand each quarter, and the totals differ from the general ledger by amounts nobody can explain.
Triangles live in spreadsheets with hard-coded links, so a late claim or a reopened file means rebuilding the grid.
Case reserve changes overwrite history in the claims system, so incurred development cannot be rebuilt as it stood at each valuation date.
Assumption tables are copied between workbooks, and nobody can say which mortality or lapse table fed last year's results.
Method selections and sign-offs sit in email, so one audit question about a line of business takes days to answer.
Finance needs reserve outputs in the layout its IFRS 17 or LDTI process expects, and someone retypes them.
Our Approach
How do we build around the actuaries without touching their methods?
Three rules shape every build. The software owns data and records; judgment stays with the actuary.
Reconcile before anything is modelled
Every load balances to the general ledger and the claims system for the period before it reaches a triangle, and the reconciliation report is stored with the data version.
Keep history as of each valuation date
Claim payments and case reserve changes are stored as dated transactions, so paid and incurred positions can be rebuilt as they stood at any past evaluation.
Record runs, not only results
Each production run is logged with its data version, model version, assumption set, outputs and the person who signed it off.
Capabilities
What do our actuarial software services cover?
We build the data and controls around the models. Rate filing exhibits and rating engines are covered on our property and casualty insurance software page.
Actuarial data mart
Claims, premium and exposure data by line, accident period and valuation date, reconciled to the ledger and the claims system at each close.
Triangle builder
Paid, incurred, reported and closed count triangles by line and accident period, with segments and lags the actuary configures.
Reserving workflow
Method runs, actuary selections, peer review and sign-off recorded per line and valuation date.
Experience study pipelines
Exposure and event data for mortality, lapse and morbidity studies in life and health, with study periods and exclusions versioned.
Model run registry
Inputs, model version, assumptions, outputs and sign-off kept for every production run and locked once signed.
Assumption library
Tables and parameters with effective dates, owners and change history, referenced by identifier instead of copied.
Data quality reports
Checks the actuary can cite: data element definitions, questionable values and comparison with the prior valuation.
Reporting feeds
Signed reserve and cash flow outputs shaped for the IFRS 17 or US GAAP long-duration contract process finance already runs.
How It Works
What does the reference architecture look like, and who owns each record?
This is the architecture we start from on actuarial builds. Each step names the team that owns its record, because ownership is usually the first thing an auditor asks about.
Source systems (owned by policy, claims and finance)
Policy administration, claims and the general ledger stay the systems of record. We read from them on a schedule and never write back.
01
1
Reconciled data mart (owned by data engineering)
Transactions land with load dates and source control totals. A reconciliation job compares premium and loss totals with the ledger and holds the load if they do not balance.
02
2
Triangle and study builder (owned by the actuarial team)
Actuaries define segments, lags and study periods as configuration. Every triangle and exposure table is tagged with the data version it came from.
03
3
Model run registry (owned by actuarial, read by audit)
Each run records the data version, model and version, assumption set, outputs and sign-off. Signed runs cannot be edited, only superseded.
04
4
Reporting feeds (owned by finance)
Signed outputs flow to the financial reporting process in the agreed layout, carrying the run identifier so finance can trace each figure back.
05
5
Engineering Stack
Data, tools and standards around an actuarial platform
We work with the modelling tools your actuaries already use and build the plumbing around them.
Data
Cloud data warehouse or lakehousePostgreSQLSQL or dbt transformationsReconciliation jobs
Actuarial tools we connect
Python and R model codeExcel workbooks with controlled inputsVendor actuarial models through their import and export files
Standards in view
ASOP No. 23, Data QualityASOP No. 56, ModelingIFRS 17US GAAP LDTI
Platform and security
Role-based access and SSOAudit loggingEncryption in transit and at restCloud hosting
Sizing
What sizes an actuarial data platform?
An actuarial data platform is sized by the lines of business, the policy, claims and finance systems it reads, the years of clean transaction history, the reconciliations finance must sign off, the models and tools it connects and the reporting outputs it feeds. Agnotic Technologies reviews each driver with your actuaries and finance team before scoping.
| Driver | Question to answer before scoping | What it changes in the build |
|---|---|---|
| Lines of business | Which lines and segments go in first, and do they share one claims and policy system? | Each line adds segment definitions, coverage mappings and its own triangle and study configuration. |
| Policy, claims and finance source systems | How many systems hold policy, claim and ledger data, including legacy books still in run-off? | Every source needs an extract, field definitions and control totals before the data mart can load it. |
| Years of clean transaction history | How far back are payments, reserve changes and claim status changes kept as dated transactions, not snapshots? | Snapshot-only history must be rebuilt or marked as a known limitation before development triangles can use it. |
| Reconciliations finance signs off | Which totals must tie to the general ledger and claims system each close, and at what level of detail? | More reconciliation points mean more balancing jobs, hold rules and evidence kept with each data version. |
| Models and tools to connect | Do reserving and pricing models run in Python or R code, controlled workbooks or vendor tools? | Each tool needs its own input layout, import or export route and an entry in the model run registry. |
| Reporting outputs | Which outputs leave the platform: reserving triangles, experience studies, regulatory exhibits or IFRS 17 and LDTI feeds? | Each output adds a layout, a sign-off step and a trace from every figure back to its signed model run. |
Measured Impact
What should an actuarial platform let you see?
Status views we build into the actuarial and finance dashboards.
Balanced
Reconciliation status
Whether each close tied to the ledger and claims system, by line.
Signed
Runs with sign-off
Production runs signed and unsigned for the current valuation.
Changed
Assumption changes
Assumption sets changed since the last valuation, with owner and reason.
Late
Late sources
Feeds that missed the data cut-off for the period.
Use Cases
Where do actuarial software projects usually start?
First releases we scope, each small enough to finish and prove on one valuation.
02
Triangle service
Paid and incurred triangles generated from the data mart instead of spreadsheets.
03
Run registry
A log of model runs, inputs and sign-off ready for the next quarterly reserve review.
04
Experience study data
Exposure and lapse data prepared for a life or health assumption review.
05
Actuarial software for startups and MGAs
A first data mart and triangle set for a young book where history is short and every period counts.
06
Finance reporting feed
Signed reserve outputs delivered to the IFRS 17 or LDTI process in the layout it needs.
Integrations
Which systems does actuarial software read from and feed?
The systems an actuarial data layer connects to, read-only on the source side.
Exposure and premium
Policy administration system
Payments and case reserves
Claims system
Reconciliation
General ledger
Ceded amounts
Reinsurance administration
Inputs and outputs
Actuarial models
IFRS 17 and LDTI
Financial reporting process
Storage
Data warehouse
Sign-off evidence
Document storage
What we check
Which data checks should an actuary be able to cite?
We build these checks into each load and keep the results with the data, so the actuary can describe data quality in the report instead of rebuilding the evidence.
Definitions
- Each data element has a written definition and a source field
- Changes to a definition are dated and logged
- Paid, incurred and reported mean the same thing across lines
Reasonableness
- Negative payments and reopened claims flagged
- Report dates earlier than accident dates flagged
- Large movements against the prior valuation listed for review
Completeness
- Premium and loss totals balanced to the ledger
- Claim counts balanced to the claims system
- Missing segments or periods reported, never filled silently
Reliance
- Who supplied each source is recorded
- Known limitations travel with the data version
- The prior valuation's data stays available for comparison
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
General Data Protection Regulation
Implement lawful consent flows, data minimization, and secure processing for global data privacy.
Service Organization Control 2
Verified controls for security, availability, and confidentiality of enterprise data systems.
Information Security Management
Adhering to the international gold standard for managing information security risks.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does an actuarial software engagement run?
We start with one line and one valuation. Timing depends on your data, and we agree a fixed first release on the scoping call.
01
Scoping call
Lines, valuation calendar, data sources and the models in use today.
02
Data inventory
Sources, definitions and reconciliation rules agreed with actuarial and finance.
03
Fixed-scope first release
One line reconciled, triangles generated and runs logged for one valuation.
04
Add lines and studies
More lines, experience studies and reporting feeds on the same data model.
05
Support through each close
Loads, reconciliations and changes handled under agreed change control.
Facts and sources
Which standards shape actuarial software?
Short facts we design around, each linked to its primary source.
When an actuary reviews data, ASOP No. 23 asks for a reasonable effort to determine the definition of each data element used and to identify questionable values or significantly inconsistent relationships, and to consider comparing current data with the data used in the prior analysis.
Source: Actuarial Standards Board, ASOP No. 23, Data Quality, section 3.3Under ASOP No. 23, the accuracy and completeness of data supplied by others are the responsibility of those who supply it; the actuary may rely on that data and should disclose the reliance.
Source: Actuarial Standards Board, ASOP No. 23, Data Quality, section 3.5ASOP No. 56 defines governance and controls as procedures and an organizational structure designed to reduce the risk that model output is not reliably calculated or not used as intended, and says the actuary should use, or may rely on others to use, reasonable governance and controls to mitigate model risk.
Source: Actuarial Standards Board, ASOP No. 56, Modeling, sections 2.3 and 3.6.4IFRS 17 Insurance Contracts is effective for annual reporting periods beginning on or after 1 January 2023.
Source: IFRS Foundation, IFRS 17 Insurance Contracts
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related pages
Related insurance and data services
This page covers the data and records around actuarial models. These pages cover the work next to it.
Property and casualty insurance software
Rating engines, filing exhibits and statistical reporting.
Captive insurance software
Ledgers and domicile filings, including actuarial filings, for captive managers.
Self-insured risk management software
Claim logs, reserves and annual reports for self-insured employers.
Data engineering services
Pipelines, warehouses and data quality checks beyond insurance.
Insurtech software development
Our wider insurance practice for carriers, MGAs and startups.
More in Insurtech
More Insurtech Solutions
Explore other production-grade engineering platforms we deliver across insurtech.
Cross-Industry Reach
The Same Engineering Patterns, Across Other Industries
The technical patterns behind this platform translate naturally into adjacent verticals.
Frequently Asked Questions
No. Agnotic Technologies is a software development services company. We build the data, workflow and records around your actuaries; method selections, opinions and sign-off stay with your credentialed actuaries.
We treat each model as a component with defined inputs and outputs. The data mart prepares its inputs, the registry records each run, and the model itself, whether code, a workbook or a vendor tool, stays as your actuaries built it.
The six drivers in the sizing table on this page set it, and source systems and clean history usually weigh most. We answer them with you on the scoping call instead of using an actuarial software calculator.
Yes, if the claims system kept dated transactions. Where it overwrote history, we capture snapshots from go-live onwards and document the gap, so the actuary knows which periods can be rebuilt and which cannot.
Yes. A young book has little history, so the first release is usually a reconciled data set and simple triangles that grow with the portfolio, plus the run records a fronting carrier or reinsurer will ask to see.
We do not do the accounting. We deliver signed actuarial outputs with their run identifiers in the layout your reporting process expects, so finance stops retyping figures and can trace each one back to a run.
Industries