> For the complete documentation index, see [llms.txt](https://docs.cdpi.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cdpi.dev/technical-notes/data-and-credentialing-infra/data-exchanges-system-to-system-data-sharing/getting-started-the-+1-approach.md).

# Getting Started: The +1 Approach

* **Start with use cases, then audit what exists.** Identify two or three high-value use cases that would deliver significant cost savings for government (e.g., social benefit transfers) or meaningful friction reduction for citizens (e.g., business registration). Then map existing infrastructure against what those use cases actually require — what APIs already exist, what systems need wrapping, where identity and authentication gaps are. The output is a target architecture grounded in reality, not a vendor's reference diagram. This feeds directly into technical requirements for procurement.
* **Phase the build aligned to use cases**. Start with what the first two or three use cases require (not with what a full data exchange platform offers), prove value with real transactions, then expand capability as subsequent use cases demand it. Each phase should have a clear success metric tied to the use case it serves, not to technical milestones.
* **Decouple governance design from platform procurement.** Governance — who can join the exchange, what standards apply, who is liable when things go wrong — should be designed as a parallel workstream, not as a byproduct of platform selection. These are distinct questions requiring distinct expertise. If governance is left to the procurement process, platform vendors will answer it in ways that serve their commercial interests. Define the governance framework first, then issue technical requirements that enforce it.

As the implementation of the larger data exchange infrastructure continues, Governments can layer on **lightweight, "+1 steps" to digitize rapidly** and start realizing benefits without having to have the full infrastructure go live.

* **Mandate open API standards and centralised authentication first.** Define national specifications (OpenAPI 3.0) and invest in unified identity and access management infrastructure.
* **Publish national data schemas.** Maintain a central directory of common data models to ensure cross-ministry interoperability. A fintech integrating tax and business registration data should not have to reconcile two incompatible address formats.
* **Wrap, don't replace.** Use sidecar proxies and database adapters to expose legacy systems as modern APIs. Most government data of value lives in systems that were never designed to share — wrapping them is faster and cheaper than replacing them.
* **Standardise consent artefacts.**<sup>**2**</sup> Implement machine-readable consent as a mandatory technical handshake for any exchange involving personal data. Define this at the national level — not agency by agency.
* **Consider Verifiable Credentials.** For datasets that change infrequently — diplomas, licences, identity attributes — evaluate Verifiable Credentials as an alternative to live API calls. A holder-bound credential eliminates real-time server dependency: once issued to a citizen's wallet, verification is local and does not require the issuing authority to be online. This reduces infrastructure load and gives citizens direct custody of their own data. Importantly, the foundations for issuing VCs — identified use cases, clean authoritative registries, and modern APIs on source systems — are the same foundations a data exchange requires. A country investing in these foundations can pursue VCs and a data exchange in parallel, treating them as complementary outputs of the same preparation work rather than sequential choices.
* **Open the rails to the private sector.** Provide secure access to open APIs to unlock innovation in fintech, agritech, health, and other sectors. The data exchange matures into digital public infrastructure when the private sector can build on the same rails that government uses.

2. Electronic Consent Framework Technology Specifications, Version 1.1. (n.d.). Retrieved June 8, 2026, [Electronic Consent Framework](https://dla.gov.in/sites/default/files/pdf/MeitY-Consent-Tech-Framework%20v1.1.pdf)