HomeGuidesAPI Reference
Guides
Start typing to search…

Introduction: Ownera Application Orchestration Layer

This page explains the technical foundation you build on:

  • What the Ownera Router does as an application orchestration layer
  • How existing applications and services become SuperApps by connecting to it
  • The two main types of SuperApps:
    • Business SuperApps
    • Utility SuperApps
  • Where Distributed Hubs (domain protocols) fit in as an advanced primitive layer

1. Ownera as an Application Orchestration Layer

The Ownera Router is an application orchestration layer for institutional finance.

It abstracts the complexity of:

  • Multi-chain / multi-ledger
    Different blockchains, tokenization platforms and traditional ledgers.

  • Multi-asset
    Funds, bonds, equities, private markets and other structured products.

  • Multi-partner
    Trading with counterparties who run different tech stacks and platforms.

  • Composable infrastructure
    Reusing shared primitives and services (pricing, collateral, cash, KYC, data rooms, analytics, etc.)
    across many applications, instead of integrating each one point-to-point.

Instead of every application integrating directly with every ledger and every partner, you:

  1. Connect your system once to the Router orchestration layer, and
  2. Express business actions as intents over investors and assets,
  3. Let the Router orchestrate execution across chains, partners and shared services.

Your existing application or service becomes a SuperApp when it is connected to this orchestration layer.

2. Make your application a SuperApp

You don’t have to “rewrite your platform and rebuild it on Ownera”.

The typical pattern is:

  • You already have:
    • A trading platform, issuance system, portal, workflow tool, data service, or other financial application.
  • You add:
    • An integration service or backend module that:
      • Talks to the Router via REST API (for actions) and GraphQL (for reads)
      • Maps your internal concepts (users, accounts, positions, orders) to:
        • investor profiles
        • asset profiles
        • Intents and orchestration results

Once this integration is in place, your application can:

  • Initiate orchestrated business flows with any partner connected to the network without bilateral integration
  • Interact with assets and investors across multiple chains and ledgers
  • Leverage composable services (collateral, cash, KYC, data, analytics, etc.) provided by other SuperApps

At that point, it is effectively a SuperApp in the Ownera ecosystem.

Architecturally, you have two options:

  • To put Router integration in a separate service, or
  • To bake it into your existing backend

The docs generally illustrate a small “Router integration service” for clarity, but both patterns are valid.

3. Types of SuperApps

On the Ownera orchestration layer, we distinguish three things:

  1. Business SuperApps – client-facing applications
  2. Utility SuperApps – services and infrastructure utilities
  3. Distributed Hubs (domain protocols) – advanced: a lower-level primitive layer for specific markets

3.1 Business SuperApps

Business SuperApps are applications used by client users – traders, sales, relationship managers, operations, investors, issuers, etc.

Typical examples:

  • Trading platforms (primary, secondary, financing, RFQ, etc.)
  • Asset issuance and distribution platforms
  • Wealth / investor portals
  • Treasury, liquidity and payments applications
  • Workflow / lifecycle management tools

Key functions:

  • Maintain their own UX, user base, business logic and data
  • Integrate with the Router to:
    • Represent investors and assets as global identities
    • Create intents that express business actions (e.g., subscribe, transfer, open financing, allocate collateral, move cash), and
    • Propose, Approve and Read back orchestration results, positions and portfolio state

By connecting to the Router, a Business SuperApp can:

  • Trade and interact with partners who run different tech stacks, through a single orchestration layer,
  • Participate in composable flows that involve other SuperApps (e.g. collateral, cash, data utilities)
  • Reuse domain protocols where they exist, instead of reinventing workflows, and

You can think of this as:

“Make your existing client-facing application a Business SuperApp by connecting it to the Router and expressing its business flows as intents.”

3.2 Utility SuperApps

Utility SuperApps are services rather than full client-facing apps.
They provide reusable capabilities to Business SuperApps and to other utilities, such as:

  • Connectivity and integration:

    • Blockchain / ledger adapters
    • FIX / ISO / SWIFT connectivity
    • Integration with custody tech, market utilities

  • Data and analytics:

    • Pricing and risk engines
    • Portfolio analytics and reporting services
    • Market data or reference data providers

  • Business support and workflow:

    • Data rooms and documentation flows
    • Compliance and screening utilities
    • Case management / workflow engines

Key functions:

  • Connect once to the Router, exposing their capabilities across the network
  • May also expose direct APIs that Business SuperApps call alongside Router flows, and
  • Make it easy for any application to reuse a shared service instead of building and maintaining its own bespoke integration

You can think of this as:

“Make your service a Utility SuperApp by connecting it to the Router, so any Business SuperApp or FI can consume it as a reusable capability.”

3.3 Distributed Hubs (domain protocols) – advanced

For composability, there is a need for a shared domain protocol that:

  • Defines or extends models, intents and orchestration plans for a market
  • Encodes the rules, roles and steps for multi-party workflows

We refer to these as Domain Protocols or Distributed Hubs.

They are:

  • A lower-level primitive layer configured on top of the Router
  • Sometimes packaged with facade APIs that make it easier for applications to participate in that protocol

Most application teams can start by focusing on:

  • Business SuperApps
  • Utility SuperApps

4. Who you are (audience view)

The orchestration layer is designed to be useful for three main kinds of builders.

4.1 ISVs and Fintechs

You build and operate applications or services that you sell to financial institutions:

  • Trading and execution platforms
  • Issuance, investor portal or workflow systems
  • Data, analytics, risk, or reporting services

You can:

  • Turn your application into a Business SuperApp
  • Turn your service into a Utility SuperApp

By integrating with the Router, you:

  • Connect once to the orchestration layer
  • Reach multiple FIs, ledgers and partner SuperApps
  • Participate in composable, multi-party flows without bespoke bilateral integrations

4.2 Market Providers

You operate a market, network, or specialized infrastructure:

  • Execution venues, matching platforms
  • Collateral or financing platforms
  • Settlement networks or specialized rails
  • Payment infrastructure providers
  • Market utilities for specific products

By connecting your platform to the Router:

  • You expose your market/service once via the orchestration layer
  • Any Business SuperApp or FI system can plug into you
  • You can interact with any partner connected to the network across multiple composable business flows (trading, collateral, cash, lifecycle events, etc.)

You may:

  • Turn your platform into a Business SuperApp for your direct users, and/or
  • Provide Utility services for others, and/or
  • Define or participate in Domain Protocols for your market (advanced).

4.3 Financial Institutions (FIs)

You operate internal systems for:

  • Trading and dealing desks
  • Issuance and distribution
  • Custody and asset servicing
  • Collateral, treasury and payments
  • Risk, compliance and reporting

By connecting your systems to the application orchestration layer:

  • Your internal applications can become Business SuperApps, interacting with external partners via the Router
  • Your internal services (pricing, analytics, data, workflow) can become Utility SuperApps
  • You can connect once to:
    • External markets and service providers
    • Other FIs’ Business and Utility SuperApps
    • Multiple chains and tokenization stacks

You gain the ability to combine:

  • Your own applications and utilities
  • Third-party Business and Utility SuperApps
  • External markets and networks

into seamless workflows, without bespoke point-to-point integration for each new partner.

5. How you integrate technically (high level)

Regardless of who you are, the technical integration model is similar.

You will:

  1. Get access to a Router environment

    • Sandbox, UAT and production
    • Receive base URLs, organization IDs, and credentials

  2. Set up authentication & authorization

    • Generate a key pair and register your public key
    • Configure API key / client identity
    • Sign requests or tokens from your backend
    • See: Authorization

  3. Represent investors and assets as global identities

    • Map your internal users/accounts to investor profiles
    • Map your products / instruments to asset profiles

  4. Call the Router APIs from your backend

    • Use REST to:
      • Create / update investors and assets
      • Create intents that represent business actions
    • Use GraphQL to:
      • Query portfolios, positions, balances and orchestration state
    • Webhook to orchestration plan events, to participate in the approval processes and synchronize internal systems.

  5. Let the Router orchestrate with partners and utilities

    • The Router coordinates workflows across:
      • Other institutions’ Routers
      • Utility services you depend on
      • Domain protocols (where applicable)

  6. Use the results inside your app

    • Update your UI, workflows and systems based on:
      • Orchestration outcomes
      • Positions and balances
      • Events and lifecycle states

6. Where to go next

From here, you can go deeper in two directions:

Updated 4 days ago