Digital Infrastructure in 2026: Buying the Service Stack

The procurement mistake in digital infrastructure this year is treating broadband, cloud migration, digital identity, payments, and citizen services as separate workstreams. Funding institutions are approving integrated transformation programs, but many buying teams still issue isolated packages for fiber, hosting, software, and support. That mismatch produces contracts that are individually compliant and collectively unusable.

Two World Bank approvals from June make the shift clear. On June 30, the Bank approved US$70 million for Pakistan's Connected Punjab Program, linking broadband expansion to faster Right-of-Way permitting, AI-enabled public service delivery, and interoperable cashless payments. On June 12, it approved a $250 million Morocco Digital Transformation Acceleration Program inside a broader $650 million package, tying digital investment to a unified national portal, a sovereign wallet linked to the national identity card, cloud adoption for new IT investments, and private capital mobilization. These are not network projects with some software attached. They are service-delivery programs whose infrastructure, regulatory, and application layers are being bought as one operating stack.

What changed in the approval logic

The Punjab program is useful because it states the delivery logic in operational terms. The World Bank says the program is meant to reduce average Right-of-Way permitting time from 90 days to 21 days, facilitate fixed broadband expansion from 7.8 million to 9.9 million people by June 2031, and enable at least US$50 million in private capital investment in digital infrastructure. It also supports government computing infrastructure for AI-powered services, targets 28.9 million people through improved digital public services, and aims to bring 350,000 people into active cashless payment use. In other words, the approval is not built around laying cable alone. It is built around the full chain from permitting to coverage, from compute to service adoption, and from invoicing to digital payment behavior.

Morocco shows the same pattern from a different starting point. The digital transformation program is framed around deployment and adoption of user-centric services, a transition to cloud systems, a unified national portal, a sovereign wallet for official documents, AI innovation capacity, and support for MSME digitization. Through risk-sharing mechanisms, it is also expected to mobilize close to $200 million in private capital for startup financing and MSME digitization. That is a very different buying problem from a standard enterprise IT refresh. The hard part is no longer choosing a portal vendor or a hosting vendor in isolation. The hard part is procuring the interfaces that let identity, documents, payments, hosting, and user journeys work together at national scale.

What buyers still get wrong

The first error is packaging by asset class rather than by operating dependency. One lot buys connectivity, another buys hosting, another buys application development, another buys payments, and everyone assumes integration will happen in governance meetings later. It usually does not. A broadband package cannot deliver the program outcome if the permitting workflow is outside the contract. A sovereign wallet cannot drive adoption if document issuance, authentication, and service access sit with different vendors on different standards. A cloud migration lot that excludes data exchange, security architecture, and cutover ownership is not an acceleration package. It is just a hosting move.

The second error is treating regulatory reform as background context rather than a procurement input. Punjab's target to cut Right-of-Way processing from 90 days to 21 days means permit workflow is part of infrastructure delivery, not an administrative footnote. If the tender does not specify authority interfaces, document standards, escalation paths, and approval service levels, the program has not bought faster rollout. It has only announced it. The same applies to digital identity, credential storage, electronic signatures, and cloud defaults. Those are governance choices, but once approved they become specification choices that determine what suppliers must integrate, certify, secure, and support.

The third error is measuring value on unit price when the real exposure is interdependency risk. A cheap fiber award that slips permitting destroys the economics of the cloud and service layers behind it. A low software price that omits integration to payment rails or identity services creates a future variation order, not a saving. Programs like these succeed when one package can be commissioned without discovering that another package defined a critical interface differently. Procurement has to test that before award, because after award each supplier will defend its own boundary and the buyer inherits the gap.

How we structure the procurement

Our working rule is simple: buy the service stack in layers, but qualify the interfaces before you buy the layers. In practice we separate the procurement into an enabling backbone, a trust layer, and a service layer. The enabling backbone covers connectivity, hosting, compute capacity, and secure exchange. The trust layer covers identity, credentials, payments, data governance, auditability, and cyber controls. The service layer covers the priority user journeys the program is supposed to improve. That split is not about multiplying vendors. It is about making each vendor bid against explicit handoffs, common standards, and measurable acceptance tests.

For the backbone layer, we want bidders to declare their Right-of-Way assumptions, third-party access dependencies, power and site requirements, backhaul handoff conditions, and service restoration commitments. For the trust layer, we want the identity federation model, credential issuance logic, API standards, audit trail ownership, and business continuity design. For the service layer, we want named transactions, adoption targets, fallback procedures, and the exact data objects that move across systems. If those items are not priced and contractually owned, the program is still at concept stage no matter how polished the strategy document sounds.

We also pay attention to the private capital claims inside the program design. Punjab is expected to enable at least US$50 million of private investment in digital infrastructure. Morocco expects close to $200 million in private capital for startup financing and MSME digitization. When those targets appear in the approval logic, the procurement package cannot behave like a closed public works contract. It needs bankable interface points, milestone evidence that a financier can test, and commercial terms that do not make the private side wait for unresolved public-side dependencies. Otherwise the capital mobilization target stays in the press release and never reaches the asset.

The useful question before the next RFQ

The important shift in 2026 is not that governments want more broadband or more cloud adoption. It is that funders are approving digital infrastructure against measurable service outcomes, adoption targets, and private capital mobilization. Buyers who still tender passive assets in isolation are no longer matching the structure of the programs they are executing.

Before the next digital infrastructure RFQ leaves the building, ask one narrow question: if every supplier delivered exactly what its package describes, would a user be able to complete a verified transaction end to end. If the answer is no, the procurement is missing the real scope. In this cycle, digital infrastructure is not bought when the fiber is installed or the cloud tenant goes live. It is bought when the whole service stack can operate together on day one.