SOLO Network Releases GraphQL for Reusable Verification & Customer Permissioned Data

New York, September 28, 2026 - Today, SOLO released its GraphQL schema for consumer and business data, designed to help banks, fintechs, and data providers retrieve and furnish verified information through a common, permissioned graph.

The release is built around a simple premise: financial institutions should be able to reuse prior verification work rather than restart every customer process from zero. SOLO’s graph connects data, verification policies, permissions, provenance, and evidence allowing a participant to retrieve what it needs for a decision while applying its own standards for governed acceptance.

“Financial data-sharing has treated every new relationship as if trust has to be rebuilt from scratch,” said Georgina Merhom, Founder of SOLO. “We are making it possible to move verified processes, not just data, so institutions can identify the remaining gap and complete only what is necessary. With the GraphQL, anyone can participate in how we do that by contributing their verifications and credentials to an open network with the right support for all those involved to confidently issue and accept work in a collaborative, governed model.”

What is SOLO’s GraphQL

SOLO GraphQL is a shared, permissioned graph of consumers and businesses. It holds over 270 data attributes and verification steps that participants can furnish to the graph and query from it. That includes profile data, the policies and verification events behind that data, and relationship or empirical data such as repayment history, account activity, and fraud signals. Because every verification in the graph is stored with its evidence and the policy it met, completed work can be issued as a credential that other institutions can discover and rely on.

As a consumer reporting agency and verification network, SOLO started by making identity and customer-provided data reusable across a closed network of sponsor banks. GraphQL is how SOLO opens that network to everyone else.

Unlike fixed, resource-based APIs, SOLO’s GraphQL interface is intended to support complex, relational queries across consumer profiles, businesses, verification events, policies, certificates, and network relationships in a single request. The architecture maintains object-level consent, permissions, provenance, and access controls across each graph relationship.

SOLO’s ontology is designed to represent consumer and business profile data, policy and verification data, and relationship or empirical data—including events such as repayment history, account activity, and fraud signals. The company has also developed transformation tooling to map external schemas into this graph, with the goal of reducing bespoke integration work for institutions and data providers.

What the Graph Enables

The GraphQL schema was designed to support SOLO’s broader network model for:

• Customer-permissioned application pre-fill: retrieving approved data to reduce repetitive onboarding steps.
• Portable verification: issuing credentials and certificates that allow institutions to rely on completed identity, business, income, or compliance workflows.
• Furnishing at scale: mapping source data into a shared ontology through API, graph, file, and integration-based workflows.
• Policy-aware access: configuring permissions and reliance requirements by field, object, and graph relationship.

What this means for the industry:

Banks can accept data and credentials issued by others, including those for digital identity, on their own terms in compliance with the recent clarifications from FinCEN. A credential delivered through the Graph is only usable if it matches the bank's own CIP and CDD policy, so no bank has to change its policy to participate. Leveraging the Graph as an acceptance layer also ensures that every verification a bank relies on comes with a digitally signed audit trail of how it was verified matched against the bank’s own standards.

Fintechs and lenders cut onboarding friction. With customer-permissioned pre-fill, approved data moves between workflows so customers stop re-entering it. With portable verification, completed identity, business, income, or compliance checks can be reused so customers skip steps they have already done.

Identity vendors, KYB providers, aggregators, and data companies can become issuers of data products to an open network, not just their closed loop ecosystem of existing customers. Credentials are discoverable across the network, even where the issuer is not the relying party's active vendor. That means more value from verification work they have already performed, without the duplicative third party risk management and operational burden that currently limits credential adoption.

Accounting firms and anyone else doing auditable customer diligence can furnish too. If you can prove the work you did, you can issue a credential from it.

For consumers and businesses, the result is fewer document uploads, fewer liveness checks, and fewer repeated forms. They only complete the steps that are actually necessary.

SOLO GraphQL Schema

The graph centers on the customer: a consumer or business profile that banks, fintechs, and data providers all furnish to and query from.

The graph records more than customer data. Every verification step is modeled as an event, and each event carries the evidence and provenance that show how the work was done and when.

The schema is built in three layers:

• Attributes: the customer data itself, such as name, address, email, bank account, assets, and credit profile.
• Verification events: the steps performed on that data, such as biometric capture, document capture, employment verification, and fraud verification. Each event links directly to the consumer or business it verified.
• Evidence and provenance fields: on every event, what was captured, its quality, when it happened, and whether and when it was reviewed.

Take a biometric capture. Instead of a single "passed" flag, the graph records the artifact type (face, fingerprint, or voice), its image quality, whether the subject was present, the artifact upload method, the capture timestamp, and whether and when the capture was reviewed. Document capture events carry the same capture and review record.

Products and policies sit on top of the schema

In SOLO's Graph view, participants explore the schema as an expandable tree or flow, for consumers and for businesses. Two things are layered over it:

• A product defines which parts of the schema a credential covers. In the example above, a KYC Certificate includes biometric and document capture events. Fields it doesn't cover are marked "Not in product."
• A self-defined policy sets the allowed values for each field. A strict policy can require that a biometric capture was reviewed, or that a document was captured within the last 5, 30, or 90 days. This view allows a bank, fintech, or issuer to see how closely aligned a credential or verification matches their own standards, like those for CIP and CDD.

A relying party doesn't ask whether a credential exists. It asks whether the recorded evidence meets its own policy, field by field.

Example: Schema Snippet

The Schema is organized by the following data types: Identity Verification, Business, Income & Employment, Fraud Signals, Banking, Investments & Assets, Credit & Liabilities, and Applications & Lifecycle data.

The below snippet depicts what is included within a set of attributes for Income on the Graph.

Why Now, Why SOLO

The regulatory interpretations on digital identity and reusable credentials were recently articulated. The network spent the last year preparing for exactly this moment.

FinCEN, together with the federal banking regulators, recently confirmed that government-issued digital credentials, such as mobile driver's licenses, count as ID under customer identification program rules. The guidance says institutions can use verifiable credentials to fulfill their CIP obligations, as long as the credential meets their own CIP and CDD policy.

That means anyone can issue credentials. It also opens up the risk considerably. Not every credential is built equal, and relying parties now need a way to tell them apart.

At the same time, recent KYC incidents have shown the danger of storing and passing around large volumes of raw identity data. The industry needs a way to share verified outcomes instead of passport images and KYC files.

Why SOLO

Issuing a credential is the easy part. Knowing whether you can rely on one is the hard part, and that is what SOLO was built to answer from day one.

A credential backed by document capture, biometrics, and a DMV check is very different from one backed by a phone number verification and a reverse lookup. Both are "credentials." Unless you validate what was actually done and match it to your policy, you cannot know whether to accept either.

SOLO works like a clearinghouse for verification work. Every credential on the network answers two questions:

1. What did you do to produce this credential? Issuers connect the workflow they used to verify the customer, and SOLO reconciles it in real time against the relying party's CIP policy.
2. Did you actually do what you said you did? Attestation is only the final step. SOLO validates it against the source of evidence.

SOLO also does not force one standard on the industry. Technical, data, and policy standards like NIST IAL2 exist, but few participants adhere to them uniformly. Waiting for everyone to converge would have meant waiting a decade. Instead, your policy decides what you rely on, across whatever vendors and standards produced the work.

How SOLO's Graph Works

GraphQL works in two directions: you can query the graph before asking a customer to start over, and you can furnish to it so your work gets reused and rebates your cost of verification.

Querying the SOLO Graph

When data is already available, SOLO can initiate a consent-to-reshare flow directly with customers. When it is not, SOLO can route to integrated data providers or prompt the customer to provide the required information through its Collect SDK.

When you query SOLO, you upload your policy and set exactly what you will accept. You can get granular. For example, your policy might reject any document that expires within the next 60 days.

SOLO then looks across the network for who has already completed those steps. Sometimes one issuer has an exact match. Sometimes several fintechs each performed part of the work, and together they corroborate a credential.

• A trusted credential exists: the customer is fast-passed.
• The data exists but needs consent: SOLO starts a consent-to-reshare flow.
• The data doesn't exist yet: SOLO routes to integrated data providers, or prompts the customer to provide it through the Collect SDK.

SOLO is also building toward natural-language access through MCP: AI assistants will be able to translate a request into the relevant GraphQL query and return the requested data without requiring users to understand underlying API structure.

Furnishing to the Graph

Any organization that performs auditable customer diligence can start furnishing in four steps:

1. Pick the attributes you can furnish. Select them from the graph's schema, such as identity, income, or business ownership.
2. Connect your workflow for evidence. Point SOLO to where the attributes live and to the evidence behind them. If you furnish identity, that is the orchestration engine you used to run it. If you verify beneficial ownership using incorporation documents, point SOLO to those.
3. Attest to your policy. Tell SOLO the standard your verification followed. SOLO validates that attestation against your evidence.
4. Get paid when it's reused. When others rely on your work, you are compensated through the network.

Furnishing can run through API, graph, file, and integration-based workflows. SOLO's transformation tooling maps your existing schema into the graph, so you avoid bespoke integration work.

Issuing credentials to the SOLO Graph

On SOLO, credentials are created from the work furnished to the graph. An issuer never has to hand over the underlying documents.

1. The verified outcome joins the customer's profile. A furnished attribute, such as a completed identity check, is linked in the graph to the evidence behind it and the policy it was verified against.
2. SOLO validates the work. SOLO reconciles the connected workflow against its source of evidence in real time. The credential records what was actually done, not just what was claimed.
3. The credential is issued with its context attached. The result is a privacy-preserving credential proving the customer met a defined policy, with provenance and a digitally signed audit trail. Passport images and KYC files stay where they are.
4. Its availability is published to the network. Relying parties discover it through a GraphQL query before starting a new workflow, even when the issuer is not their vendor.
5. Each relying party checks it against its own policy. SOLO matches the credential's recorded steps to the relying party's CIP policy. When no single issuer has an exact match, steps performed by several issuers can corroborate each other into one credential.

Because every credential is built on the same shared graph and schema, a credential issued by a bank, a fintech, or an IDV vendor can be read and evaluated by any participant, without a point-to-point integration.

Access GraphQL

The GraphQL release is accompanied by API documentation, credential issuance capabilities, custom network templates, and configurable policy controls. SOLO is also pursuing collaboration with banks, identity and KYB providers, open-banking participants, and aggregators to validate and extend the shared schema.

“Financial teams shouldn’t have to build a patchwork of APIs just to understand a customer,” said Georgina Merhom, CEO of Solo. “SOLO makes it possible to ask for the data you need, with the right permissions, in one place.”

Get API documentation, credential issuance, and policy controls, and start querying or furnishing to the graph. Request GraphQL access with the form below.