Skip to content
S&S Labs
§02.1Solutions/ Government & public services

Still asking applicants to carry certificates from office to office?

A shared registry for public services

One exchange layer that lets agencies verify each other's records at the source, with no central database.

A records officer scanning a paper file in an archive of shelved boxes and bound registers.
Type
Solution
Sector
Government & public services
Capabilities
Architecture & Transformation, Software & Platforms
Built for
Public agencies and the services that depend on their records

§1Context and challenge

Context and challenge

Several public agencies each hold part of a citizen's or a business's record: identity, registration, licences, tax status. A typical service needs evidence from three or four of them, so the applicant collects paper certificates and carries them from office to office.

The challenge

Let a service verify the facts it needs directly from the agency that owns them, in seconds, with the citizen's consent and a full audit trail, while every agency keeps control of its own data and systems.

What changes

Fewer visits and documents for applicants, faster decisions for agencies, and verification that can be trusted because it comes from the source.

What we deliver

Enterprise architecture, interoperability design, the exchange gateway, agency verification APIs and a first connected service.

§2Solution and architecture

Our solution.

An interoperability layer rather than a central database. Each agency publishes a small set of verification APIs behind a shared gateway that handles authentication, consent, logging and rate limits. Services query facts ("Is this business registered and in good standing?") instead of copying records. A signed, verifiable certificate is issued when a paper document is still required.

Exchange-layer architecture

Exchange-layer architecture. Components:

  • Online service (interface): Applicant portal
  • Exchange gateway (core): Auth · consent · audit
  • Registry API (service): Agency A
  • Licensing API (service): Agency B
  • Tax status API (service): Agency C
  • Agency A records (store)
  • Agency B records (store)
  • Agency C records (store)

Connections:

  • Online service to Exchange gateway
  • Exchange gateway to Registry API
  • Exchange gateway to Licensing API
  • Exchange gateway to Tax status API
  • Registry API to Agency A records
  • Licensing API to Agency B records
  • Tax status API to Agency C records
Reference architecture, adapted to your systems.

§2.1The interface

What your team works in.

The interface we deliver, shown here with sample data.

Case desk

Queue CS-4471

Business licence renewal

A. Kariuki, sole trader · submitted 12 Oct online

Your decision

Evidence, verified at source

  • Business registrationActiveRegistry, 10:15
  • Tax statusIn good standingTax authority, 10:15
  • Previous licenceExpires 31 OctLicensing records, 10:16
  • FeeUSD 45.00 paidMobile money, 10:21

Approval

  1. Case officerRecommended, 11:02
  2. 2SupervisorYour decision
  3. 3Licence issuedAutomatic
ApproveRequest informationReturn

§3Engineering decisions

The decisions that matter.

  1. D1

    Verify facts, don't copy records

    Services ask yes/no or minimal-attribute questions. Less data moves, less data is exposed, and agencies stay the single source of truth.

  2. D2

    Federated, not central

    No new national database to secure and maintain. Agencies connect at their own pace; the gateway provides the shared trust services.

  3. D3

    Consent and audit as platform features

    Every query carries the purpose and the citizen's consent reference, and is logged where both the agency and an oversight body can review it.

  4. D4

    Open standards

    Documented REST APIs and standard signatures, so any vendor can build a connected service and no single supplier controls the exchange.

§4Implementation approach

Implementation approach

  1. 01

    Map

    Choose one high-volume service and trace every document and visit it requires today.

  2. 02

    Pilot

    Connect the two or three agencies that service depends on, through the gateway.

  3. 03

    Prove

    Run the service end-to-end with real users; measure visits, documents and decision time.

  4. 04

    Extend

    Publish the standards and onboard further agencies and services in waves.

§5How we measure success

The measures we agree with you before we start, and report against.

  • Visits and paper documents required per application
  • Time from application to decision
  • Share of verifications answered automatically
  • Agency onboarding time to the exchange

Next solution

Document intelligence for credit operations

Have this problem?

Tell us how it shows up in your organization. We'll show you how the solution fits your systems and what it takes to put it to work.

Start a projectOr explore the Systems Lab