The Router Fundamentals

Overview

FinP2P Routers form the backbone of FinP2P —a fully trusted connections between financial institutions that enables secure, peer-to-peer communication and application orchestration layer. These routers are the critical infrastructure components that make cross-ledger transactions possible, ensuring reliable message delivery and full agreement among all participating parties.

The Ownera FinP2P engine is the main component which handles the various operations included in the FinP2P specification, it orchestrates, delegates and oversees the safe execution of the operations by enforcing idempotency, privacy and recoverability. The engine layer is decomposed into multiple service layers which are responsible for different aspects of the FinP2P specification; those modular services may be composed and deployed in multiple variations to support different use cases.

Services of the FinP2P engine layer are required to provide safe, fault tolerant and reliable operations, to do so those services utilize a proprietary workflow execution engine which provides robustness to the FinP2P transaction processing and assures consistency of data while working across multiple transactional boundaries and physical network boundaries.

Ownera architecture is composed of multiple services which are built to provide reliable and fault tolerant execution of the FinP2P operations; asynchronous APIs, events, message passing and idempotent operations are leveraged to assure reliable operation of the underlying system.

What are FinP2P Routers?

FinP2P Routers are specialized software components that enable direct peer-to-peer communication between financial institutions while orchestrating cross-ledger financial transactions through full agreement mechanisms. Each financial institution in the FinP2P network operates its own router, which connects directly to other institutions' routers, creating a mesh network of trusted participants. These routers ensure secure and reliable message delivery without any intermediaries, data sharing between parties and maintaining temporal state throughout the process and guaranteeing settlement finality through distributed agreement.

The fundamental role of a router extends beyond simple message passing. Routers actively participate in the orchestration of complex financial flows, ensuring that all parties involved reach agreement at every step. They serve as the trusted orchestration environment for each institution, translating high-level business intents into concrete operations on underlying ledger systems while maintaining cryptographic proof of every action taken.

Network Architecture

Peer-to-Peer Communication Model

The FinP2P network operates on a pure peer-to-peer model where routers communicate directly with each other without intermediaries. Each router establishes direct connections to counterparty routers using the FinP2P gRPC messaging protocol, creating a mesh topology that ensures resilience and eliminates single points of failure. This architecture means that when two financial institutions need to transact, their routers communicate directly, with no third party able to intercept, delay, or modify their messages.

This direct communication model is fundamental to the trust and efficiency of the network. By eliminating intermediaries, the system reduces latency, removes unnecessary points of failure, and ensures that sensitive financial information is shared only between the parties directly involved in a transaction. The mesh topology also provides natural redundancy—if one connection experiences issues, the network continues to function normally for all other participants.

Router Discovery and Registry

Routers discover one another through a registry mechanism that maintains a list of FinP2P router addresses and identities. In controlled environments, such as private networks between specific financial institutions, router addresses are exchanged through agreed governance processes.

Each router's identity is cryptographically verified before establishing connections, ensuring that only authorized financial institutions can join the trusted network. This verification happens at multiple levels—from the network layer where IP addresses are whitelisted, to the protocol layer where cryptographic signatures are validated. The registry serves not just as a directory but as a trust anchor for the entire network, defining who is authorized to participate and under what terms.

Communication Guards

Protocol Guards: Message Sealing

At the protocol level, every FinP2P message is cryptographically signed by the sender's FinID (the cryptographic identity of the router). This signature covers both the message envelope and payload, creating an immutable seal that serves multiple purposes. Recipients verify these signatures against a trusted list of configured parties, ensuring that messages originate only from authorized sources. The cryptographic signing ensures message integrity—any attempt to modify the message in transit would invalidate the signature and cause the recipient to reject it. Furthermore, this creates non-repudiation, meaning senders cannot deny having sent authenticated messages, which is crucial for regulatory compliance and dispute resolution.

The message sealing protocol goes beyond simple authentication. It creates a cryptographic chain of accountability where every action taken by every router is permanently recorded and attributable. This becomes particularly important during transaction orchestration, where multiple parties must coordinate their actions—the signatures serve as binding commitments to specific operations.

Network Guards: Access Control

The network layer provides additional security through strict access control mechanisms. Financial institutions configure their routers to accept connections only from specific, pre-approved addresses. This creates a closed network environment where unauthorized parties cannot even attempt to connect. Network-level restrictions, often implemented through firewalls and network segmentation, ensure that traffic flows only between known router endpoints.

This network-level security serves as the first line of defense, preventing unauthorized access attempts before they even reach the protocol layer. It also provides protection against various network-level attacks, including denial of service attempts, by limiting communication to a known set of trusted parties. The combination of network and protocol security creates multiple barriers that an attacker would need to overcome, significantly raising the bar for any potential security breach.

Message Structure and Protocol

FinP2P Message Components

Every FinP2P message is structured with three essential elements that work together to ensure secure, reliable communication. The envelope contains crucial metadata about the message, including sender and receiver identification, a unique request ID for tracking and correlation, and timestamp information for ordering and timeout management. This metadata enables routers to properly route, track, and manage messages throughout their lifecycle.

The payload carries the actual business content of the message—this might be an intent specification from an investor, orchestration instructions for a complex transaction, or status updates about ongoing operations. The payload is designed to be flexible enough to carry any type of financial transaction data while maintaining a consistent structure that all routers can process.

The signature component provides cryptographic proof of the message's authenticity and integrity. Created by signing both the envelope and payload with the sender's FinID private key, this signature can be verified by any receiving party using the sender's public key. The signature ensures that the message has not been tampered with and definitively identifies its source.

Message Flow

FinP2P supports multiple communication patterns to accommodate different transaction needs. The most common pattern is request-response, where a router creates a message with the appropriate envelope and payload, signs it with its private key, and transmits it directly to the recipient router. The receiving router validates the signature against its list of trusted parties—rejecting any messages that don't verify or come from unknown parties—then processes the content and sends back a signed response.

Beyond request-response, the protocol also supports streaming-based communication for scenarios requiring continuous data flow or real-time updates. In streaming mode, routers can establish persistent connections that allow for ongoing message exchange without the overhead of individual request-response cycles. This is particularly useful for monitoring transaction progress, receiving market data updates, or coordinating complex multi-step operations where parties need continuous synchronization.

Regardless of the communication pattern, every message maintains full cryptographic integrity through signing and verification. The receiving router always validates signatures before processing, and the sender always verifies response signatures, creating an auditable trail of the entire interaction. This security model remains consistent whether handling single request-response pairs or managing long-lived streaming connections..

State Management and Data Synchronization

Operational Persistency and Resource Sharing

Routers maintain different types of state for different purposes, each with its own lifecycle and sharing model. At the core, each router maintains operational persistency for its own functioning needs—configuration data, connection states, message queues, and other infrastructure requirements that enable the router to operate reliably. This operational data is private to each router and institution, ensuring that internal operations remain isolated and secure.

Beyond operational needs, routers implement sophisticated resource sharing abilities that allow controlled data exchange between parties. When institutions need to share information—whether for a transaction, market data, or other business purposes—routers facilitate this sharing through secure, authenticated channels. The protocol ensures that data is shared only with intended recipients and that all parties can verify the authenticity and integrity of shared information.

Orchestration State Synchronization

For orchestration plans, routers maintain specialized state that is in sync across all participating parties. This orchestration persistency is transaction-specific, temporal for only for the duration of the orchestration plan. The protocol ensures that relevant parties maintain synchronized views of this state through a structured update mechanism where each state change is signed, distributed, and acknowledged by all participants.

Integration with Ledger Systems

Ledger Adapters

Routers connect to underlying ledger systems through specialized adapters that serve as the translation layer between the FinP2P protocol and ledger-specific operations. These adapters abstract away the complexity and differences between various blockchain and DLT platforms, presenting a consistent interface to the router while handling the unique requirements of each underlying system. Whether connecting to a public blockchain like Ethereum, specialised networks like Canton, or a traditional database system, the adapter ensures the router can interact seamlessly.

The adapter layer handles the asynchronous nature of different ledger systems, managing varying confirmation times and finality mechanisms. Some ledgers might provide instant finality, while others require waiting for multiple block confirmations. The adapter manages these differences, providing consistent feedback to the router about operation status and generating standardized receipts that other parties in the network can verify and trust.