UK software suppliers should prepare for APIs that share defined customer data, manage permissions and establish who may connect. They should avoid committing to a supposed universal Smart Data specification. The government’s May 2026 response summarises stakeholder views and explicitly does not set policy. For small and mid-sized suppliers, the practical move is to improve existing interfaces while keeping future scheme requirements separate from today’s development commitments.
The decision for a small UK software supplier
An application programming interface, or API, lets software request data or actions from another system through a defined interface. The commercial question is whether your product would supply data, consume it for customers, or do both.
The Act’s explanatory notes describe powers to require access to customer data and provision of contextual business data. They explain an intention to support sharing at the customer’s request in real time. That is broader than treating portability as a downloadable file.
Consider a hypothetical UK subscription-management application. Its customer might want to combine usage records from several services with information about available plans. A useful interface would need to distinguish that customer’s records from general product information, and establish which application has permission to retrieve them.
This is an illustrative use case, not an announced scheme or a claim that particular suppliers must expose those records. It gives a small development team a concrete design question without pretending that the final dataset is settled.
What the law establishes and what remains undecided
The commencement regulations brought Part 1 into force. The explanatory notes describe regulation-making powers through which requirements can be imposed. Suppliers should distinguish those enabling powers from the detailed obligations of an applicable scheme.
The strongest policy evidence supplied here is the response updated on 12 May 2026. It says explicitly that its analysis does not set out government policy or prejudge future decisions. Its 54 submissions therefore demonstrate engagement with the proposal, not agreement on an implementation timetable. Government response
The available evidence does not establish a final digital markets API specification, a universal implementation deadline or which software suppliers would be covered. A procurement brief should leave those questions open until the applicable rules and specifications are available.
Data protection remains a separate consideration. The government explains that the Act changes, but does not replace, the UK GDPR, Data Protection Act 2018 and Privacy and Electronic Communications Regulations. Treat a customer’s sharing permission as something to assess alongside the applicable data-protection requirements, rather than a complete legal assessment in itself. Government privacy guidance
This is not legal advice; consult your legal counsel.
The API capabilities worth preparing
CTC’s engineering recommendation is to prepare separable capabilities, then map them to a scheme when its requirements become clear. The table describes a proposed design, not mandated endpoints or an approved standard.
| Capability | What to prepare | Who should own the decision |
|---|---|---|
| Customer-data access | Defined records, field meanings, stable identifiers and customer boundaries | Product owner and data engineering lead |
| Product and service information | A separate model for contextual information such as plan terms, where relevant | Commercial owner and API team |
| Sharing permissions | A record of who authorised access, its scope, status and withdrawal | Product, security and privacy leads |
| Participant onboarding | A way to check an application's identity and, where required, scheme status | Security and integration teams |
| Operational evidence | Records of requests, failures and access decisions, with appropriate retention | Operations and privacy leads |
The UK’s banking API standard illustrates why the surrounding infrastructure matters. Its 5 specification families are Read/Write API, Open Data API, Directory, Dynamic Client Registration and MI Reporting. The last covers management information reporting. Together, they extend beyond the endpoints that return customer records.
That precedent is useful for planning responsibilities. It does not establish that a digital markets scheme will require banking payment interfaces, the same registration process or the same reporting format.
Make the data contract understandable
Before adding endpoints, document what each field means. For the hypothetical subscription application, a usage figure would need an account identifier, measurement unit and reporting period. Otherwise, two technically successful connections could still produce an invalid comparison.
The Government Digital Service API guidance recommends starting with developer needs, checking existing APIs and separating business logic from underlying storage structures. It applies to government and public services. Private suppliers can use it as a design reference without presenting it as a Smart Data obligation.
Make withdrawal testable
Our recommendation is to test withdrawal alongside initial connection. Record the granted scope, remove access through the customer-facing control, and verify that subsequent requests are rejected.
The rationale comes from the consultation response, which reports demands for meaningful, granular and revocable consent. Government response The exact technical mechanism remains a design choice until the relevant scheme specifies it.
Stopping further retrieval also needs a separate discussion from handling information already received. Assign responsibility for that question before promising customers what a disconnect button achieves.
How the components and responsibilities connect
In the proposed design, the customer begins a connection from a receiving application. The data-holding supplier checks the requester and the permitted scope before releasing the allowed records. Both parties retain enough operational evidence to investigate a failed or disputed request.
Keep the source business system behind an access layer rather than letting an external application query its database directly. Give the integration team responsibility for translating internal records into the external data model.
A small supplier should also assign a named operational owner. If access stops working during a customer’s renewal review, someone must be able to distinguish an expired permission, a rejected participant, missing source data and an unavailable service.
These are proposed operating arrangements. The scheme’s eventual rules would determine which responsibilities belong to the holder, recipient, operator or another participant.
Costs to include before commissioning development
The supplied evidence does not support a GBP implementation price. The 2024 Smart Data impact assessment leaves headline costs and benefits unmonetised. It is not a quotation for a software supplier’s integration project.
Request a cost breakdown that separates:
- Data preparation including field mapping, inconsistent identifiers and missing records.
- Interface development including permissions, documentation and integration tests.
- Operation including hosting, monitoring, support and incident investigation.
- Scheme participation including any assurance or reporting requirements once established.
- Change and exit including specification updates, provider handover and replacement interfaces.
For an existing product, first assess what its current API can support. Reusing an interface deserves consideration before commissioning a parallel service, provided it can enforce the required access boundaries and data contract.
Ask bidders to distinguish fixed deliverables from assumptions. An estimate that excludes data cleanup or ongoing support should not be presented as complete total cost of ownership.
Comparing suppliers and delivery approaches
The evidence pack contains no comparable product documentation or quotations for AWS, Google Cloud, UK integration providers or open-source API platforms. It therefore cannot support a ranking of those suppliers or a claim that any is ready for a future digital markets scheme.
Use the same acceptance criteria across several bidders. Require each to explain who implements the data model, who operates permissions, who resolves incidents and what the customer can export when leaving.
| Delivery approach | When to consider it | What to establish before choosing |
|---|---|---|
| Extend the existing product API | Your team already owns a maintained interface | Whether its permissions and data model can support the proposed use case |
| Commission a managed cloud implementation | You want an external team to deliver or operate components | The split between platform charges, implementation work and ongoing support |
| Use a UK integration specialist | Internal capacity is limited or source systems need substantial mapping | Named deliverables, support hours, subcontractors and handover rights |
| Build around self-hosted components | Your team wants operational control and can maintain the service | Licensing, patching, resilience, support and upgrade ownership |
This is an editorial comparison of delivery choices. A supplier’s location, cloud platform or use of open-source software does not establish conformity with an unspecified scheme.
Editorial analysis
The most useful investment now is a documented data contract and a permission model your team can explain and test. Both give a future scheme implementation something concrete to build on.
Avoid signing a broad “Smart Data readiness” project whose acceptance criteria depend on rules that have not been established in the supplied evidence. Commission a bounded assessment instead. Its output should identify the records you hold, the interfaces you already operate, the gaps in customer control and the unresolved scheme assumptions.
For a small supplier, that produces a usable development backlog without turning a policy consultation into an invented compliance deadline.
Sources
- DSIT — Smart Data opportunities in digital markets, consultation overview, updated 12 May 2026
- DSIT — Data (Use and Access) Act 2025 collection
- UK legislation — Commencement No. 1 Regulations 2025, made 21 July 2025
- DSIT — Smart Data opportunities in digital markets, consultation text, updated 12 May 2026
- DSIT — Smart Data opportunities in digital markets, government response, updated 12 May 2026
- UK legislation — Data (Use and Access) Act 2025 explanatory notes, legal background
- UK government — Data protection and privacy changes, published 27 June 2025
- Open Banking — API specifications
- Government Digital Service and Central Digital and Data Office — API technical and data standards, updated 19 July 2024
- Department for Business and Trade — Regulatory powers for Smart Data impact assessment, dated 23 October 2024
