Networks

A network is the trust boundary of p SOLO platform. It groups the participants who have agreed to share data, the products they can use, the policies that govern those products, and the data that gets furnished. Everything you do — furnishing, querying, applying policies — happens within a network you belong to.

What a network represents

A network is a logical grouping that ties together three things:

Participants — the entities that operate within the network (see Network Roles)
Data — every furnished record carries a network reference, so the network acts as a boundary on what data can be read
Rules — the querying policies and furnishing policies that govern each product, and how data is allowed to move between this network and neighbouring networks (see Network Governance)

A network has a name, an optional description, and a single governor entity that owns it.

The network tree

Networks are not flat. Every network has at most one parent network, so networks form a tree where smaller, more specific networks live underneath broader ones. A network with no parent sits at the top of the tree and is called a root network. Networks below it are its descendants; the networks directly under it are its children. In the diagram above, Coastal Bank is a child of Federation Root and a parent of Coastal — Credit Cards. Summit Bank is a sibling of Coastal Bank because they share a parent. Coastal — Credit Cards and Summit — Auto Loans are cousins because they share a common ancestor (the Federation) without being in each other’s direct line. This lets a single arrangement — such as a sponsor bank and the fintechs it sponsors — share a parent network while keeping each participant’s data within its own boundary.

Relations between networks

These are the words SOLO uses to describe how any two networks relate. They show up throughout the permissioning model, so it’s worth getting them straight up front.

Term	Meaning
Parent	The network directly above this one.
Child	A network whose parent is this one.
Ancestor	Any network reachable by walking upward — parent, grandparent, and so on, up to the root.
Descendant	Any network reachable by walking downward — child, grandchild, and so on.
Sibling	Two networks that share the same parent.
Cousin	Two networks that share a common ancestor but are not in each other’s ancestor or descendant line.
Root	A network with no parent.

SOLO treats siblings as a special case of cousins for permissioning purposes. Anywhere governance rules talk about cousins, siblings are included.

Standard networks and subnetworks

Networks come in two kinds, distinguished by their network_type:

Standard networks are the default. A bank, a consortium, or a fintech operating in SOLO each runs as a standard network. These are typically created through the SOLO Dashboard.
Subnetworks are child networks of a standard network that represent a specific product or initiative the operator runs — a credit card line, a mortgage line, a partnership offering. Subnetworks are usually created automatically by SOLO’s data-furnishing workflows when a subnetwork definition first arrives through bulk ingestion (see Network lifecycle).

Subnetworks always sit beneath a standard parent network. They behave like any other network in the tree — they can have their own participants, their own data, and their own governance settings — but their lifecycle is typically tied to the upstream data flow that created them. When you furnish, you name the subnetwork so the network can route the data and resolve the right furnishing policy:

{
  "network_id": "9f1c0c2e-…",
  "subnetwork_name": "acme-lending",
  "application_date": "2026-05-28",
  "records": [ /* … */ ]
}

If you operate a single product line, you probably only need a standard network. Subnetworks become useful when you want to keep data, participants, or rules isolated between distinct product offerings under the same operator.

Network lifecycle

Standard networks and subnetworks come into existence in different ways, and it’s worth understanding both paths.

Standard networks: created through the dashboard

Standard networks are created deliberately, through the SOLO Dashboard, as part of onboarding your organization or standing up a new arrangement (a consortium, a sponsorship structure, a new line of business). A new network needs:

a name and an optional description,
an optional parent network, which places it in the tree, and
a governor entity — the entity that owns and administers it.

The entity that creates the network is recorded as its governor entity, and SOLO automatically provisions that entity’s governor membership on the new network at the same time. This means a freshly created network is never ownerless: from the first moment, exactly one entity can administer it, add participants, and configure its governance rules. After creation, the governor typically:

adds participants with the roles they need (furnisher, querier, or additional governors),
creates and configures the querying policies and furnishing policies for the products the network will use, and
optionally enables governance rules to open query paths to related networks.

Subnetworks: created by furnishing workflows

Subnetworks usually aren’t created by hand. They are created automatically by SOLO’s data-furnishing workflows when a subnetwork definition first arrives through bulk ingestion — typically a subnetworks workbook delivered over SFTP or via file upload. The workflow creates a child network with network_type: subnetwork underneath the standard network the definition was furnished into, named after the subnetwork, and links it to the furnishing policies named in the definition. Two properties of this flow are worth knowing:

Only the network’s governor can introduce subnetworks. Subnetwork definitions furnished by an entity that doesn’t govern the target network are rejected.
Subnetwork names are unique within their parent network. A definition that re-uses an existing subnetwork name in the same network fails for that row rather than silently overwriting the existing subnetwork.

From then on, every furnish that names that subnetwork_name is routed into the subnetwork, and the subnetwork’s furnishing-policy assignments determine how the data is accepted (see Furnishing Policies). Furnishing data with a subnetwork_name that doesn’t exist in the target network is an error — the subnetwork definition has to arrive first. Because a subnetwork’s lifecycle is tied to the upstream data flow that created it, you generally don’t delete or restructure subnetworks directly — you stop furnishing into them, or deprecate the policies assigned to them.

Permissions & roles

Your organization joins a network with one or more roles. Roles describe what you can do, not what data you can see.

Role	What it allows
Governor	Administer the network — configure policies and directory metadata. A governor seat is not a backdoor to other members’ data.
Furnisher	Contribute data into the network for a product.
Querier	Run product queries scoped to the network.

A single organization can hold several roles at once (for example, both furnisher and querier). See Network Roles for the full model.

Governing a network does not automatically let you read what other members have furnished. Reading another participant’s data still requires consent and entitlement. Roles grant capabilities, not visibility.

Policy usage within a network

A network ties products to participants through policies:

A querying policy binds a product to the network and defines, field by field, what queriers may read.
A furnishing policy defines how furnished data for a product is accepted, validated, and routed.

When you query, you scope the request to one or more network ids and a querying policy, so the network knows both where to read and which reading rules apply. When you furnish, the network resolves the applicable furnishing policy from the network, subnetwork, and application date automatically — you never pass a furnishing policy id yourself.

Joining a network

Membership and roles are arranged with your SOLO account manager. Once you’re a member, you can:

search for entities within the network,
furnish products into it (as a furnisher), and
query products from it (as a querier, with consent).

See the quickstart for a walkthrough.

In the dashboard

Network created — detail page with new network

Networks list — newly created network visible

Network Roles

How entities participate in a network.

Network Governance

How data can flow between related networks.

Querying Policies

The field-level read rules a network applies to each product.

Furnishing Policies

How furnished data is accepted, validated, and routed.

Entitlement

Why network membership alone doesn’t grant data access.

Trust model

Networks & Governance

Entities & Consent

What a network represents

The network tree

Relations between networks

Standard networks and subnetworks

Network lifecycle

Standard networks: created through the dashboard

Subnetworks: created by furnishing workflows

Permissions & roles

Policy usage within a network

Joining a network

In the dashboard

Network Roles

Network Governance

Querying Policies

Furnishing Policies

Entitlement

​What a network represents

​The network tree

​Relations between networks

​Standard networks and subnetworks

​Network lifecycle

​Standard networks: created through the dashboard

​Subnetworks: created by furnishing workflows

​Permissions & roles

​Policy usage within a network

​Joining a network

​In the dashboard

​Related concepts

Network Roles

Network Governance

Querying Policies

Furnishing Policies

Entitlement

What a network represents

The network tree

Relations between networks

Standard networks and subnetworks

Network lifecycle

Standard networks: created through the dashboard

Subnetworks: created by furnishing workflows

Permissions & roles

Policy usage within a network

Joining a network

In the dashboard

Related concepts