Network contribution

​

Contributing is asset creation, not data donation

• You keep attribution. Every certificate sub-product your data backs carries your furnishing_entity_id and attestation_id. The verification travels with your name on it — see Provenance.
• You keep governance. Contributed data is still gated by the subject’s consent, the network’s querying policy, and each reader’s entitlement. Furnishing does not expose your data to passive observers.
• You gain read access. Contributing is how you earn entitlement to read a subject back later (see below).

​

Why furnish?

1. It’s how the network has anything to say. Every certificate, attestation, and screening result a querier receives traces back to a record some furnisher contributed. A network where nobody furnishes is an empty database with a governance layer.
2. It earns you read access. Furnishing an entity makes you entitled to that entity’s data on future queries. Contributing is one of the two ways to earn entitlement — the other is a prior query. For most participants, furnishing the entities you already onboard is by far the cheapest way to build broad read coverage across the network.

​

The three furnishing channels

• REST furnish when furnishing is an event in your system — a consumer finishes onboarding, you furnish their record in the same workflow. Lowest latency, immediate feedback, no file handling.
• Bulk file upload when you have a periodic batch job and an HTTPS client but don’t want to manage SFTP credentials or a file-transfer pipeline.
• SFTP when your data already leaves your systems as files on a schedule. Most core-banking and data-warehouse stacks can target an SFTP endpoint with zero custom code, which makes it the usual choice for nightly or monthly drops.

​

How a furnish works

​

Anatomy of a REST furnish

curl -X POST https://api.solo.one/v1/products/kyc_certificate/furnish \
  -H "Authorization: Bearer $SOLO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "network_id": "9f1c0c2e-7a44-4f1e-9d2a-08b6f3a1c5d7",
        "subnetwork_name": "default",
        "application_date": "2026-05-28",
        "records": [
          {
            "first_name": "Jane",
            "last_name": "Doe",
            "date_of_birth": "1990-01-15",
            "social_security_number": "123-45-6789"
          }
        ]
      }'

{
  "success": true,
  "submission_id": "5b2e9f10-3c7d-4e8a-b1f6-2d9c0a47e831"
}

• network_id — the network you’re furnishing into. You must hold the furnisher role there.
• subnetwork_name — names the subnetwork inside that network. Together with application_date, this is what the network uses to resolve the applicable furnishing policy.
• application_date — when the consumer applied. Used in policy resolution (see below), not as a record timestamp.
• records — one or more consumer records. For KYC certificates each record carries first_name, last_name, date_of_birth, and social_security_number — all strings. The SSN is the matching key that connects your record to a consumer entity.

​

Subnetwork routing and policy resolution

1. Subnetwork lookup. subnetwork_name is resolved to a subnetwork inside the network identified by network_id. An unknown subnetwork name fails the record — subnetworks must be configured by the network’s governor before furnishers can target them.
2. Policy matching. Each subnetwork is linked to one or more furnishing policies, each link carrying an effective date window. Your record’s application_date is compared against the policy’s active window and the subnetwork-link’s effective window. Policies whose windows cover the application date apply; records that fall outside every window are filtered — skipped without being treated as errors.

​

What happens after ingest

1. Validation. The record is checked against the resolved policy’s requirements. Each record is processed independently — one bad record in a batch doesn’t fail its neighbors.
2. Entity matching. Identifiers in the record (SSN for consumers; tax identifier and jurisdiction for businesses) are matched to an existing entity, or a new entity profile is created. Re-furnishing the same entity updates the existing profile rather than creating a duplicate.
3. Records become network data. The furnished attributes are written as that entity’s data, attributed to your organization as furnisher.
4. Certificates and attestations. For certificate products, the furnished operations (document capture, address verification, and so on — whatever the policy requires) become the evidence behind KYC/KYB certificates that queriers later receive. Where your organization has attested to the data, the attestation is linked to the resulting certificates.
5. Entitlement is recorded. Your organization becomes entitled to this entity’s data on future queries.

​

Data quality expectations

• Identifiers must be real and complete. SSNs, EINs, and dates of birth are matching keys. A typo doesn’t just corrupt one record — it creates a phantom entity or pollutes a real one.
• Treat identifiers as text. SSNs and tax identifiers are strings, not integers. This matters in spreadsheets especially: a numeric cell silently drops leading zeros.
• application_date should be the genuine application date. It drives policy resolution; backdating or defaulting it to “today” routes records to the wrong policy version.
• Furnish what the policy asks for. Policies enumerate required verification operations. Records that don’t satisfy them won’t produce certificates, even if they ingest cleanly.
• Idempotency is on natural keys. Re-submitting a consumer record with the same SSN updates rather than duplicates. Don’t “fix” a bad record by furnishing a second one with a tweaked identifier.

​

Furnishing vs. querying

​

Troubleshooting

​

In the dashboard

​

Related concepts