# Orbital for financial services

> Connect market data, core systems, Open Banking APIs and reporting workflows using the schemas you already have. Orbital handles the mappings and orchestration as systems change.

Source: https://orbitalhq.com/industries/finance

Financial Services

# Orbital for **Financial Services**

Connect market data, core systems, Open Banking APIs and reporting workflows.  
  
Orbital handles the mappings and orchestration as systems change.

[Get Started](/docs)[Talk to us](/contact)

Use cases

## **Integrate,** simply.

Banks run on systems built across decades — APIs, databases, feeds and streams, each with their own protocols and data models.

Orbital adds a semantic layer across them, then builds the integration each workload needs, on demand.

**Onboard data feeds in minutes**

Add semantic types to data feed schemas and publish. Orbital maps the feed into the different models your pricing, risk, trading and analytics systems already use.

What used to take weeks or months of integration work becomes a few minutes of schema tagging.

[Connecting data sources](/docs/describing-data-sources/open-api)

Annotate the Open Banking schema with semantic types, then use those same types across your internal APIs and databases.

Orbital works out how to populate the Open Banking contract from the systems underneath — including joins and transformations across multiple sources.

[Semantic types in Taxi](https://docs.taxilang.org/language-reference/types)

Build reports from governed data across operational systems, with lineage for every value returned.

When a number is questioned, trace it back through the transformations and service calls to the source record that produced it.

Changes to source systems or reporting schemas are handled against the semantic model rather than buried in another set of report-specific mappings.

[Lineage and tracing](/features/observability)

Bring trades, positions, cash and reference data into a common model, even when each system represents them differently.

Use that model to build reconciliation and exception workflows without first creating another consolidated data pipeline.

[Querying across systems](/docs/querying/writing-queries)

## Run inside your security boundary.

Orbital deploys into your environment and works with the security infrastructure you already have. Data stays in the systems that own it, rather than being copied into another platform.

![](/assets/plate-policy-BrOQ8GtA.webp)

-   ### Deploy in your cloud
    
    Run Orbital inside your own cloud or network, so sensitive data doesn’t have to leave your environment.
    
-   ### Bring your own identity
    
    Integrate with any OIDC or SAML identity provider. Keep the users, groups and access controls you already have.
    
-   ### Keep your data at home.
    
    Orbital routes data between your systems without copying it into a separate data platform or warehouse
    
-   ### Keep your secrets
    
    Connect Orbital to your preferred secret store, so credentials stay managed by the systems you already trust.
    

## Write once, **enforce everywhere** data authorization

Define authorisation by data type and field, then enforce it consistently across APIs, databases, streams and agents.

Policies can use live data from connected systems when making access decisions — not just static roles and permissions.

[Explore Universal Authorisation](/features/universal-authorisation)

![A policy applied to a response, showing which fields were returned in full, which were masked, and for whom.](/assets/policies-DaM1P9DW.svg)

## Give agents **governed access**

Let agents work across accounts, payments, customer data and internal systems through a single interface

Orbital works out which systems and operations are needed for each request, with orchestration and controls enforced outside the LLM.

[Explore Universal MCP](/solutions/universal-mcp)

-   ### Field-level access control
    
    Control exactly which data agents can read or change, with fine-grained policies enforced on every request.
    
-   ### Keep sensitive data out of the LLM
    
    Mask sensitive values before they reach the model, then restore them when the response comes back.
    
-   ### Audit every data access
    
    Record exactly which data elements were accessed, by who and when.
    

## 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 existing APIs, databases, streams and files. Systems of record remain where they are; the semantic layer describes how their data relates.

Add semantic types to the incoming schema so Orbital understands what each field represents. The feed can then be normalized into the types your downstream applications already consume, without building another set of point-to-point mappings.

Apply semantic types to the Open Banking contract and to the internal APIs and schemas that can supply those values. Orbital uses those types to plan the integration required to satisfy the Open Banking request.

Orbital records where each returned value came from, including the systems called and transformations applied along the way. Individual report fields can be traced back to the source data that produced them.

Yes. Orbital integrates with existing identity providers and can enforce policy down to individual types and fields. Policies can also use live data from connected systems when making an access decision.

No. An LLM can translate plain-language intent into a query, but planning, authorisation and execution happen in Orbital outside the LLM.

## Start with **one integration**.

Bring an API, feed or reporting workflow you already have. Add semantics to the schemas, and let Orbital build the integration.

[Get Started](/docs)[Talk to us](/contact)

![](/assets/banner-cta-graph-axsXt434.webp)