Step by Step Implementation Path

This guide walks you through the typical journey of building an institutional-grade application on Ownera. Whether you're evaluating the platform or planning your integration, this page provides a mental model for how abstract capabilities translate into concrete implementation steps.

Key Insight: Your Router represents your institutional domain. It interacts with other Routers in a peer-to-peer network where trust and liability boundaries are split by design - each party is responsible for their own institutional elements while participating in orchestrated flows across multiple parties, chains, and assets. This architecture is what makes institutional software scalable across many partners.

Two Integration Paths

Before diving into the steps, understand which path applies to your use case:

The steps below are presented linearly, but steps 1-4 represent a setup phase that can be approached in parallel based on your specific needs.

The Implementation Journey

The implementation journey consists of three phases:

Setup Phase (Steps 1-4) - Establishing your foundational elements: users, assets, counterparties, and service connections. These steps can be approached in parallel based on your specific needs.

Business Activity Phase (Steps 5-6) - Where Business Applications focus. This includes creating and executing intents, participating in orchestrations initiated by other parties, and tracking execution in the business context.

Infrastructure Phase (Steps 7-8) - Where Utilities and Connectors focus. Building the adapters and data services that power the network.

Step 1: Map Users and Wallets

What you're doing: Establishing the identity layer that connects your users to the network.

In Ownera, each user has a User Profile ID (their legal identity) and one or more User FinIDs (their cryptographic wallet identities). This separation allows you to support multiple custody models - self-custody, segregated custody, or omnibus accounts - all under a unified identity framework.

The practical flow:

1. Onboard investor/user profiles - Register your users with the platform, establishing their legal identity
2. Connect with custody/key management - Integrate with your chosen custody or key management solution
3. Associate cryptographic keys - Link wallet addresses and signing capabilities to user accounts
4. Attach certificates - Add identity certificates, compliance attestations, and other credentials to user profiles

API Integration Points:

Certificates: User profiles can include various certificate types for identity verification, compliance attestations, and regulatory requirements. See the FinP2P Certificates Specification for details on owner certificates.

Mental Model: Think of the User Profile as the "who" (legal entity) and the FinID as the "how" (the cryptographic capability to sign and transact).

Step 2: Map Assets and Their Representations

What you're doing: Establishing which assets your application can access and operate on.

Assets in Ownera have an Asset Profile ID - a concrete, tradable asset representation that can be exchanged across counterparties. The Financial Identifier on that profile connects multiple ledger-specific assets to a single logical financial asset representation, enabling unified operations across chains.

Coming Soon: Auto-aggregation capabilities at the financial asset level will further simplify multi-chain asset management.

Two approaches based on your access model:

• Direct access: Register assets you access directly via your Router - this includes assets you issue, or assets on public chains that you can access directly without going through another party
• Indirect access: Use assets that counterparties share with you - issuers or custodians share their assets, which you can then query via the Query API and operate on via intents

The practical flow:

1. Identify your asset sources - Direct ledger access, custodian-provided, or issuer-provided
2. Register or enable assets - Create asset profiles or connect to existing ones
3. Associate with connectors (direct access only) - Link assets to the adapters that provide access to their capabilities. For indirect access, this is handled by your custodian or issuer.

API Integration Points:

Coming in v0.26: The Adapter Operational API enables you to register new adapters (connectors) and associate the assets you register with the connector that provides access to the asset's capabilities.

Step 3: Register Counterparties

What you're doing: Establishing trusted peer-to-peer connections with other institutional Routers.

Each financial institution operates their own Router, identified by an Org FinID. Counterparty registration creates the trust basis for communication - you explicitly permission which other Routers your Router will communicate with.

The practical flow:

1. Identify counterparty Routers - Determine which institutions you need to transact with
2. Establish trusted connections - Permission your Router to communicate with counterparty Routers
3. Configure communication policies - Set rules for how your Router interacts with each counterparty

API Integration Points:

Key Concept: This is a peer-to-peer trust model. Your Router only communicates with Routers you've explicitly permissioned, maintaining clear institutional boundaries while enabling multi-party workflows.

Step 4: Discover and Connect with Applications

What you're doing: Solution design - determining which existing applications and services to leverage versus build.

This is a planning and discovery phase where you evaluate the ecosystem of available Utilities and Business Applications. You may choose to:

• Leverage existing Utilities for capabilities like custody, payments, or blockchain access
• Integrate with existing Business Applications for specific financial services
• Build new capabilities where needed

The practical flow:

1. Explore the SuperApp ecosystem - Browse available Utilities and Business Applications
2. Evaluate build vs. leverage - Determine which capabilities to build versus consume
3. Connect with software and service providers - Work with providers to connect with your Router:
   • Application providers connect via API keys you provide to permission their access on your Router
   • Service providers connect by establishing Router-to-Router connections, enabling participation in intent flows

API Integration Points:

Solution Design Question: Are you going to use existing financial service providers as part of your solution, integrate existing systems, or build new ones? This decision shapes your integration complexity.

Learn More: See SuperApp Architecture for detailed information about how solutions connect and the available deployment models.

Step 5: Define and Utilize Business Intents

What you're doing: Expressing business outcomes and participating in trading activity - both initiating orchestrations and participating in orchestrations initiated by other parties.

Business Intents are the core abstraction of Ownera. Instead of coding against specific chains, contracts, or custody APIs, you declare what business outcome you need. The Router translates this into the correct execution path.

🏢

Business Application Focus: This is where Business Applications spend most of their integration effort - creating intents, executing on intents, and tracking orchestration plans in the business context.

Available Intent Types:

The practical flow:

1. Identify required intents - Map your business flows to intent types
2. Create intent requests - Define the business parameters (asset, quantity, parties, terms)
3. Execute intents - Trigger the intent and let the Router handle orchestration
4. Participate in counterparty intents - Respond to and execute on intents initiated by other parties
5. Control orchestration events (optional) - Use the Ledger Adapter API or Proxy API to receive and control orchestration plan events as part of your business process

API Integration Points:

Mental Model: An intent is "what" you want to achieve. The Router figures out "how" - which chains, contracts, custody operations, and counterparty coordination are needed.

Step 6: Administrate Orchestration Plans

What you're doing: Configuring policies, monitoring execution, and resolving exceptions - the administrative and operational layer of orchestration management.

When you create an intent, the Router automatically translates it into an Orchestration Plan - a coordinated sequence of actions across all participating parties. The plan is agreed upon by all counterparty Routers before execution begins.

🏢

Business Application Focus: Configure policies, monitor execution, and handle exceptions.

🔧 Utility Focus: This is typically where Utility/Connector development begins - implementing the adapters that execute plan steps.

What happens automatically:

• Intent → Orchestration Plan translation
• Multi-party plan agreement across Routers
• Step-by-step coordinated execution
• Deterministic execution with full audit trail

What you configure and control:

1. Orchestration policies - Define rules for how plans are approved and executed
2. Plan approval participation - Optionally participate in plan approval via webhook callbacks or by pulling events using the Adapter Proxy API
3. Step validation - Optionally participate in validating each execution step
4. Exception handling - Monitor and resolve orchestration exceptions via workflow management (continue/reset functionality)

API Integration Points:

Optional Participation: Depending on your use case, you can participate in plan approval and step validation either via webhook callbacks (push) or by polling for events using the Proxy Adapter API (pull). This is optional and depends on your compliance and risk requirements.

Step 7: Build Connectors

What you're doing: Creating connectors to blockchains, custody systems, payment rails, or legacy platforms.

🔧

Utility Focus: This is the primary focus for Utility/Connector developers. If you're building a connector to a specific chain or protocol, you may focus exclusively on this step.

Conenctors are the bridge between Ownera's unified abstraction layer and the underlying infrastructure. They implement standardized interfaces that the Router uses to execute operations.

Two Integration Models:

Adapter Types:

The practical flow:

1. Choose your adapter type - Based on what system you're connecting
2. Implement the specification - Build to the standardized interface
3. Register your adapter - Make it available to the Router
4. Test thoroughly - Validate all operations work correctly

Implementation Examples:

• Building an Asset Distribution Platform - Ledger adapter for tokenization
• Building a Payment Escrow Service - Payment adapter implementation
• Building a Custody Service - Custody adapter implementation

API Integration Points:

Step 8: Build Data Utility Applications

What you're doing: Creating data-focused services that enhance the ecosystem - analytics, reporting, compliance monitoring, and more.

🔧

Utility Focus: Data utilities provide value-added services that other applications can leverage.

Detailed guidance for building data utility applications is coming soon.

Summary: API Integration Flow

Next Steps

Now that you understand the implementation journey:

• SuperApp Architecture - Explore deployment patterns and architectural options
• Hello World Sample - Get hands-on with your first integration

Key Takeaway

The power of Ownera lies in the separation of concerns:

• Business Applications provide full business function services (steps 1-6) - trading, issuance, lending, and other complete business capabilities
• Utilities/Connectors provide micro-function services within larger business contexts (steps 6-8) - the adapters and infrastructure that power the network
• The Router handles the complex orchestration across parties, chains, and systems

This architecture lets you build institutional-grade applications that scale across the entire tokenized financial ecosystem - without building point-to-point integrations with every counterparty, chain, or service provider.