# Orbital for insurance > Connect policy, claims, billing, underwriting, broker and partner systems using the estate you already have. Orbital handles the mappings and orchestration as platforms, products and services change. Source: https://orbitalhq.com/industries/insurance Insurance # Orbital for **Insurance** Connect policy, claims, billing, underwriting, broker and partner systems. Orbital builds and maintains the integrations as your products, partners and platforms change. [Get Started](/docs)[Talk to us](/contact) Use cases ## **Integrate,** simply. Insurance workflows rarely stay in one system. Claims, underwriting and broker journeys span policy, billing, customer data and external providers. Orbital works across those systems and builds the integration each workflow needs, on demand. **Get new distribution channels live faster** Brokers, marketplaces and embedded insurance partners each bring their own API contract and data requirements. Tell Orbital what the fields in the partner contract mean. It works out how to fulfil them from policy, rating, customer and billing systems. [Semantic types in Taxi](https://docs.taxilang.org/language-reference/types) **Change the claims flow as the process changes** Add a fraud check, repair partner or new digital claims step without wiring the whole journey together again. Tag policy, claimant, coverage and loss data across the systems that hold it. Orbital plans the calls, joins and transformations each claims flow needs when it runs. [Querying across systems](/docs/querying/writing-queries) **Reuse underwriting data across products** Claims history, customer records and external risk data already exist across your estate. Different products need different combinations of them. Tell Orbital what the relevant fields mean — policyholder, claim amount, risk score and so on. Orbital can then assemble the combination each product needs, wherever the data lives. [Connecting data sources](/docs/describing-data-sources/open-api) **Move books to the new core at your own pace** Keep legacy and new policy platforms running side by side while products and books move across at their own pace. Channels keep working with the same policy and customer concepts. Orbital works out which system currently owns the data and routes each request there. [Querying across systems](/docs/querying/writing-queries) Reporting & Lineage ## **Trace every reported value** back to its source. Insurance reporting pulls data through policy, claims, finance and actuarial systems, often with calculations and transformations along the way. When Orbital assembles report data, it captures provenance as it runs. Each reported value can be traced through the calls and transformations that produced it. - ### Field-level provenance See where an individual reported value came from, not just which systems contributed to the report. - ### Track the transformations See the joins, calculations and transformations applied between the source data and the final value. - ### Captured at runtime Provenance is captured during execution, so it reflects the path the data actually took — not documentation that can fall out of date. ## Keep policy and claims data in your estate. Orbital runs inside your environment and routes data between systems without copying it into another data platform. It works with the identity and secret stores you already use. ![](/assets/plate-policy-BrOQ8GtA.webp) - ### Deploy in your cloud Run Orbital inside your own cloud or network, so policyholder and claims data does not have to leave your environment. - ### Keep your data at home Orbital routes data between your systems without copying it into a separate data platform or warehouse. - ### Bring your own identity Integrate with any OIDC or SAML identity provider and keep the users and groups you already manage. - ### Keep your secrets Connect Orbital to your preferred secret store, so credentials stay managed by the systems you already trust. ## Define once. **Enforce everywhere.** Control who can see or change policyholder, policy and claim data, down to individual fields, then apply the same rule across APIs, back-office tools and agents. Policies can use live context — assigned adjuster, broker relationship, claim status or jurisdiction — when deciding what a caller can see or change. [Explore Universal Authorisation](/features/universal-authorisation) ![A policy applied to insurance data, showing which fields were returned, masked or withheld for a caller.](/assets/policies-DaM1P9DW.svg) Enterprise AI ## **Give agents capabilities**, not microservices Give agents access to policy, claims, customer and payment operations without exposing the service estate directly to the model. Orbital works out which services to call and handles the orchestration deterministically. Identity, authorisation and sensitive-data controls are enforced before anything reaches the model. [Explore Universal MCP](/solutions/universal-mcp) - ### Keep orchestration outside the LLM The agent asks for the data or action it needs. Orbital works out which services to call and in what order. - ### Enforce security outside the LLM Credentials stay in your secret store. Field-level authorisation and masking are applied before sensitive data reaches the LLM. - ### Audit what the agent touched See which services were called, which fields were returned or changed, and which user or agent made the request. ## Frequently asked questions Got another gnarly question? We’d love to hear it. Come and chat on [Slack](https://join.slack.com/t/orbitalapi/shared_invite/zt-697laanr-DHGXXak5slqsY9DqwrkzHg). No. Orbital works across the policy, claims, billing, CRM, partner APIs, databases and services you already run. Your systems of record stay where they are. A claims flow can need policy, coverage, customer, fraud and third-party data held in different systems. Tell Orbital what those fields mean, and it works out the calls, joins and transformations needed for the flow. Yes. Describe what the fields in the external contract mean, and do the same for the systems underneath it. Orbital works out how to fulfil each request across policy, rating, customer, billing and other services. Yes. Legacy and new policy platforms can run side by side while books and products move across. Orbital can route each request to the system that currently owns the policy, without exposing that change to every downstream integration. Yes. Access policies can use live data when making a decision — for example the assigned adjuster, broker relationship, claim status, jurisdiction or individual fields being requested. No. Agents ask for the data or action they need. Orbital works out which services and operations to call, while orchestration, authorisation and execution stay outside the LLM. Yes. When Orbital assembles data, it records where each value came from and the calls, joins and transformations that produced it. Because provenance is captured at runtime, it reflects the path the data actually took rather than a design-time map. ## Start with **one workflow**. Bring a claims flow, broker API or underwriting integration you already have. Start with its existing schemas, and let Orbital work out the integration. [Get Started](/docs)[Talk to us](/contact) ![](/assets/banner-cta-graph-axsXt434.webp)