The consultation creates a bounded decision
The Competition and Markets Authority (CMA) opened a consultation on 20 October 2026 on a proposed near field communication (NFC) access conduct requirement for Apple's mobile platform. The consultation closes on 17 November 2026. The CMA will assess responses before making a final decision.¹
For a UK payment team, the immediate question is how much discovery work the proposal justifies. The draft could widen the technical routes available for contactless services on iPhone and change the commercial terms attached to access. It also names account-to-account payments as one of the possible NFC uses.²
That creates a credible product opportunity for banks, fintechs, payment firms and platforms. The opportunity still depends on a final CMA decision, Apple's implementation terms and a complete regulated service model. A useful decision today should fund the work that reduces those uncertainties and preserve the option to build when the evidence is strong enough.
What the CMA is proposing for iPhone contactless access
The proposed requirement seeks effective access to NFC on fair, reasonable, transparent and non-discriminatory terms. The draft would continue access through Apple's Secure Element route and add access through host card emulation (HCE). Developers would be able to request either route, subject to limited exceptions and compliance with applicable law and industry standards.²
The two routes handle credentials differently. HCE uses software and device hardware outside the Secure Element. The CMA describes an HCE model in which sensitive information is held off-device and a limited set of one-time tokens is sent to the device. A Secure Element uses a dedicated chip in the device to hold sensitive data and manage NFC communication.²
The proposal also reaches beyond the radio interface. Its draft terms cover supporting iOS functionality, the ability for a user to set an eligible app as the default contactless app, a way for developers to identify default status, authorisation processes and complaint handling. The CMA is also consulting on principles for access fees and other terms. It has not set a fixed price in this consultation.³
These details affect product scope, architecture, onboarding time and unit economics. They remain proposals until the CMA completes the consultation and makes its decision.
NFC access is one layer in the payment proposition
NFC can provide a familiar initiation gesture at a physical terminal. A complete account-to-account payment proposition must also identify the payer's bank, obtain valid customer authority, create and track the payment, present an accurate outcome, recover from uncertainty and give the merchant evidence it can use.
The archive's app-to-app Pay by Bank patterns remain relevant because mobile orchestration continues after the tap. Routing, return paths, state management, fallback and telemetry still determine whether the journey works as a service. The Pay by Bank checkout analysis adds the customer perspective: selection, confirmation and repeatable behaviour need deliberate design.
The regulated operating model also needs to be explicit. A developer may need its own permissions, an authorised payment provider or a contractual structure that allocates the relevant activities and controls. The CMA proposal does not grant permission to provide payment services. Apple's current public requirements for in-store NFC payments already refer to financial institutions, licensed payment providers and binding partnerships with an authorised provider.⁴
Discovery work that earns its place now
A bounded discovery phase can answer questions that will remain useful across several possible CMA outcomes. It should produce evidence for an investment decision rather than a speculative prototype with no route to approval.
Start with one customer and merchant use case. Define where the tap happens, what the customer expects to occur, which account-to-account payment instruction follows and what proof allows the merchant to complete the sale. Include the fallback for an ineligible device, unavailable bank, rejected authorisation or uncertain payment status.
Then map the operating parties. Record who provides the app, NFC credential, payment initiation, bank connectivity, merchant acceptance, customer support, fraud controls and reconciliation. Attach the permission, contract and evidence requirement to each role. This prevents platform access from being mistaken for a complete operating model.
The discovery should test five decision areas:
- customer value, including whether a tap removes a real journey barrier for a defined segment;
- merchant acceptance, including terminal behaviour, till integration, confirmation and exception handling;
- technology route, with HCE and Secure Element assumptions recorded separately;
- regulated delivery, including permissions, provider dependencies, customer authority and accountability; and
- economics, using ranges for access fees, provider costs, support, fraud, certification, terminal integration and ongoing assurance.
Each output should state which fact comes from current documentation, which assumption depends on the final CMA decision and which recommendation belongs to the product team.
Compare HCE and Secure Element against the service
The proposed choice between HCE and Secure Element should be assessed against the transaction, risk model and operating constraints of the service. A generic technology preference will produce weak architecture.
Apple's current UK NFC and Secure Element route provides a useful evidence baseline. Apple's documentation requires an entitlement, an agreement, eligibility for the intended use, applicable security and privacy controls, a configured product in Apple Business Register and an independent review of the applet. Physical-device testing is required because the relevant card-emulation session is unavailable in the simulator.⁴ Apple also documents responsibilities for credential provisioning, transaction authorisation, applet security and applicable certifications.⁵
The HCE route in the CMA draft introduces another possible implementation path. Teams should identify which service requirements depend on credential location, offline behaviour, terminal protocols, user authentication, lifecycle management and platform support. They should also record which conclusions rely on draft CMA terms because the final scope may change.
This work can produce an options paper and risk register now. Detailed build estimates should carry explicit conditions for final platform APIs, access criteria, fees, testing routes and release timing.
Keep the commercial case conditional
The CMA says technical access and commercially viable terms are connected. Its proposal sets principles for how access should be provided and expects charges to be substantially lower than Apple's current fees. The CMA is not proposing a fixed price.³
A board paper should therefore use scenarios. Model a credible range for platform access, regulated provider costs, transaction processing, certification, integration, operations, support and merchant deployment. Show the customer or merchant behaviour required for each scenario to reach its target return.
The commercial case should also value the option created by the discovery work. A team may decide that a defined customer segment and merchant channel justify continued preparation, while contract and build approval wait for final terms. Another team may find that terminal reach, regulated dependencies or adoption evidence are too weak and set a clear monitoring trigger instead.
Set a build-entry evidence gate
The proposal deserves a named decision gate. Before approving a build, the accountable product and technology leaders should require:
- a final CMA position and a verified implementation timetable;
- current Apple access, eligibility, fee, testing and distribution terms for the chosen route;
- a confirmed regulated operating model with contracts and control ownership;
- merchant and customer evidence for the chosen use case, including fallback and support; and
- an end-to-end acceptance plan covering authorisation, payment state, confirmation, reconciliation and recovery.
The production acceptance strategy provides a way to turn those conditions into scoped evidence. Procurement teams can carry the same requirements into the provider RFP scorecard so platform, payment and supplier assumptions remain visible in selection and contracting.
A sensible decision on 22 October
The CMA consultation gives UK payment teams enough substance to run focused discovery, document dependencies and decide whether to submit evidence before 17 November. It also gives leadership a clear reason to keep architecture and commercial commitments conditional.
The strongest outcome from this stage is a small set of verified choices: the customer and merchant problem, the preferred route and its alternatives, the regulated operating model, the acceptance evidence and the conditions that unlock investment. That work will remain useful when the CMA publishes its decision and Apple confirms the UK implementation terms.
Footnotes
- Competition and Markets Authority, Proposed NFC access conduct requirement for Apple's mobile platform, consultation landing page. Link
- Competition and Markets Authority, Consultation: NFC access conduct requirement, chapters 1 to 3. Link
- Competition and Markets Authority, CMA outlines proposals to unlock contactless technology on Apple iPhone. Link
- Apple Developer, NFC and SE Platform for secure contactless transactions. Link
- Apple Platform Security, NFC and SE Platform security. Link