The tax engine behind a cross-border policy

Write one insurance policy across six countries and you have not written one tax problem — you have written six, and they disagree with each other. IPT Quote is the engine that resolves them: a rate database, a quote workflow and an API that tells a broker which taxes apply, who pays them and who has to administer them. Toobler built and ran it for TMF through most of the 2010s.

Customer and context

TMF needed a product, not a spreadsheet. Insurance premium tax is a per-country, per-line-of-business, per-insurer-domicile question, it changes on dates set by legislators rather than by software releases, and getting it wrong is a regulatory problem rather than an accounting one.

IPT Quote answers that question three ways: a rate database maintained by tax specialists, a stepped quote workflow for people pricing a policy, and a Rate Check API for brokers who want the answer inside their own systems. It runs multi-tenant — global brokers and carriers each have their own instance, their own data and, in several cases, their own compliance requirements about where that data may sit.

Toobler engineered the platform, the admin console behind it, the API, and the AWS estate it ran on.

The challenge

• The domain resists simplification. A tax does not merely exist or not. It is admitted or non-admitted, borne by the insurer or the insured, and administered by a third party or not — and the combination is the answer a broker actually needs.
• The answer depends on where the insurer lives. The same policy in the same country produces a different tax subclass depending on the insurer’s country of domicile.
• Countries are not the unit. Tax is set at state, province and territory level in several of the largest markets, so the geography has to nest.
• Rates change on legislative dates. A quote written last March must still be reproducible against the rates that applied last March, not today’s.
• Every tenant is a compliance boundary. Separate data, separate instances, and in some cases a contractual constraint on which region the backups may touch.
• The clients audit their supplier. Several commissioned their own penetration tests against the platform — the release gate was somebody else’s security team.

The solution

A regulation matrix, rendered as a sentence. The admitted and non-admitted combinations are held as structured fields and turned into the statement a broker reads — “Paid by: Insurers, Admin by: Insured or their Agent”. The modeling is unglamorous and it is the whole product: get the matrix wrong and every downstream number is confidently incorrect.

Domicile-aware subclass resolution. Tax subclass is resolved by joining the insurer, the rate and the insurer’s country of domicile, with an applicability flag controlling when domicile matters at all. This is the rule most competitors flatten, and flattening it produces answers that look right.

Date-effective rates, with history. Every rate carries its effective dating, the API is addressed by effective date, and the admin console has a rate-history view filterable by line of business, country and rate. A quote is reproducible because the rate that produced it is still addressable.

Jurisdictions that nest. Countries carry parent/child relationships so US states, Australian states and territories, Canadian provinces and Chinese provinces are first-class tax jurisdictions rather than a note in a field. The platform also had to survive the real-world mess underneath that — including two countries sharing a country code and quietly returning the wrong tax type.

A configurable basis of calculation. Rather than hard-coding how a tax is computed, the engine takes a configurable basis with banding limits and multipliers, extended per country as new regimes appeared. Alongside it, apportioned-premium mathematics splits a multi-territory premium across its jurisdictions, with decimal precision configurable per tenant because some regimes demand more of it than others.

One API across two databases. A rate check needs the shared rate master and the tenant’s own instance data, which live in different databases on different servers. The API federates both in a single query path, so a caller asks one question and does not learn how the storage is arranged.

A golden-master differ for the API rewrite. When the API was rewritten, the team built a tool whose only job was to compare the old and new JSON output and report the differences. Rewriting an API that regulated customers depend on is not a question of whether the new one works — it is whether it returns exactly what the old one returned, and that is a question you answer with a diff rather than a test plan.

Cron observability, as a feature. The FX feed that keeps currency conversion current logs every run to the admin console with its status, the number of rates updated and a link to that day’s rates, and emails a warning when it fails. Scheduled jobs that fail silently are how a tax platform serves yesterday’s numbers without anyone noticing.

Backup and restore in the product. Daily backups of every tenant database to S3, listed in the admin console, restorable from it. Built as a feature rather than a runbook, so recovery did not depend on an engineer being awake.

An AWS estate run as part of the product. EC2 and RDS with alarms across the metrics that matter, S3, DNS-failure monitoring, and an instance-configuration console where per-tenant feature flags sit beside controls to start, stop and resize the infrastructure itself. Data-residency constraints were honored where tenants required them, and maintenance windows were scheduled around the working hours of users in other time zones.

Results

IPT Quote ran as a multi-tenant product for global brokers and carriers across most of the 2010s, with Toobler responsible for the application, the API, the admin console and the cloud estate underneath.

What it demonstrates is the shape of regulated software. The hard part was never the arithmetic — it was modeling a domain where the correct answer depends on four dimensions at once, keeping every historical answer reproducible, proving a rewrite changed nothing, and operating it for customers whose own security teams were entitled to test you. That combination is what separates a tax product from a tax spreadsheet.