Skip to main content
A network is the trust boundary of the 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.
TermMeaning
ParentThe network directly above this one.
ChildA network whose parent is this one.
AncestorAny network reachable by walking upward — parent, grandparent, and so on, up to the root.
DescendantAny network reachable by walking downward — child, grandchild, and so on.
SiblingTwo networks that share the same parent.
CousinTwo networks that share a common ancestor but are not in each other’s ancestor or descendant line.
RootA 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 programs

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.
  • Program networks are child networks of a standard network that represent a specific product or initiative the operator runs — a credit card program, a mortgage line, a partnership offering. Programs are usually created automatically by SOLO’s data-furnishing workflows when a program definition first arrives through bulk ingestion (see Network lifecycle).
Programs 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 program so the network can route the data and resolve the right furnishing policy: 
{
  "network_id": "9f1c0c2e-…",
  "program_name": "acme-lending",
  "application_date": "2026-05-28",
  "records": [ /* … */ ]
}
If you operate a single product line, you probably only need a standard network. Programs 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 programs 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:
  1. adds participants with the roles they need (furnisher, querier, or additional governors),
  2. creates and configures the querying policies and furnishing policies for the products the network will use, and
  3. optionally enables governance rules to open query paths to related networks.

​
Programs: created by furnishing workflows

Program networks usually aren’t created by hand. They are created automatically by SOLO’s data-furnishing workflows when a program definition first arrives through bulk ingestion — typically a programs workbook delivered over SFTP or via file upload. The workflow creates a child network with network_type: program underneath the standard network the definition was furnished into, named after the program, 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 programs. Program definitions furnished by an entity that doesn’t govern the target network are rejected.
  • Program names are unique within their parent network. A definition that re-uses an existing program name in the same network fails for that row rather than silently overwriting the existing program.
From then on, every furnish that names that program_name is routed into the program network, and the program’s furnishing-policy assignments determine how the data is accepted (see Furnishing Policies). Furnishing data with a program_name that doesn’t exist in the target network is an error — the program definition has to arrive first. Because a program’s lifecycle is tied to the upstream data flow that created it, you generally don’t delete or restructure programs 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.
RoleWhat it allows
GovernorAdminister the network — configure policies and directory metadata. A governor seat is not a backdoor to other members’ data.
FurnisherContribute data into the network for a product.
QuerierRun 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, program, 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.

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.