INTRODUCTION

While PSD2 provided the legislative framework for open banking across Europe, the United Kingdom went further. On 9 August 2016, the Competition and Markets Authority (CMA) published its Final Report on the retail banking market investigation, concluding that three separate Adverse Effects on Competition (AECs) existed in the personal current account (PCA) and small-to-medium enterprise (SME) banking sectors. The remedy was unprecedented: the Open Banking Remedy—a requirement for the nine largest retail banks to develop and adopt an open API standard.

The CMA Order 2017 (officially the Retail Banking Market Investigation Order 2017) is the world’s first legally mandated open banking API specification. Unlike PSD2, which provides a general framework, the CMA Order specifies exact technical requirements: the API must be RESTful, must use OAuth 2.0 with FAPI 1.0 Advanced, must expose specific endpoints for account information and payment initiation, and must be governed by an independent Implementation Entity (now Open Banking Limited).

This lesson deconstructs the CMA Order’s key articles (10, 12, 13, 14, 57, 58), maps each to specific API behaviours, and quantifies the compliance burden on the CMA9 banks. You will learn the phased rollout timeline, the mandatory uplift to FAPI 1.0 Advanced (v4.0), and the operational requirements for Variable Recurring Payments (VRPs)—the CMA’s mechanism for enabling automated sweeping between accounts.

LEARNING OBJECTIVES

Upon completing this lesson, you will be able to:

1. Cite the specific articles of the CMA Order 2017 (10, 12, 13, 14, 57, 58) that mandate the creation of the Implementation Entity, the release of product and transaction data, and the CMA’s enforcement powers.

2. Identify the nine mandated banks (the “CMA9”) and their phased rollout obligations, including the mandatory uplift to FAPI 1.0 Advanced by Q1 2023.

3. Quantify the API throughput baseline for CMA9 banks—25 RPS per TPP client ID during peak hours (9:00-17:00 GMT) and 10 RPS during non-peak—as specified in OBIE Management Information (MI) reporting requirements.

4. Design a VRP (Variable Recurring Payment) consent and sweeping flow, including the OAuth 2.0 consent grant, the 90-day re-authorisation cycle, and the idempotent payment submission with x-idempotency-key.

5. Evaluate the operational risk of non-compliance—including CMA directions under Article 58, public reprimands, and the potential for forced re-implementation of API infrastructure.

6. Articulate the governance structure of Open Banking Limited (OBL), including the roles of the Standards Board, Directory Service, and MI Data Reports in maintaining compliance.

PART 1: THE CMA MARKET INVESTIGATION AND THE ORDER 2017

1.1 The Three Adverse Effects on Competition (AECs)

On 6 November 2014, the CMA initiated a market investigation into retail banking services for personal current accounts (PCAs) and small-to-medium enterprise (SME) accounts. The Final Report (August 2016) identified three AECs:

1. Weak customer engagement and low switching — customers rarely switched banks, reducing competitive pressure.

2. Lack of transparency in product/service quality — customers could not easily compare bank performance.

3. High barriers for new entrants — data asymmetry prevented fintechs from offering innovative services.

The Open Banking Remedy was designed to dismantle the third AEC by mandating read/write API access for the nine largest banks.

1.2 The CMA Order 2017 — Key Articles

Article 10.6 provides for the Implementation Trustee (with CMA approval) to make changes to the Agreed Timetable and Project Plan—giving the CMA flexibility to enforce compliance if banks fall behind schedule.

1.3 The CMA9 — The Nine Mandated Banks

The nine banks required to implement the Open Banking Standard are:

+-----------------------------------------------------------------------+
|                         THE CMA9 BANKS                                 |
+-----------------------------------------------------------------------+
|                                                                        |
|  1. Allied Irish Bank (AIB Group UK) / First Trust Bank (NI)           |
|  2. Bank of Ireland (UK)                                               |
|  3. Barclays Bank plc                                                  |
|  4. Danske Bank                                                        |
|  5. HSBC Group (including First Direct and M&S Bank)                   |
|  6. Lloyds Banking Group plc                                           |
|  7. Nationwide Building Society                                        |
|  8. NatWest Group (RBS)                                                |
|  9. Santander UK                                                       |
|                                                                        |
+-----------------------------------------------------------------------+

Each CMA9 bank is required to:

1. Fund the Open Banking Implementation Entity (OBIE) proportionally.

2. Implement the Open Banking Standard (currently v4.0, with FAPI 1.0 Advanced).

3. Submit Management Information (MI) to OBIE for compliance monitoring.

4. Publish API endpoint availability metrics (Article 13).

PART 2: THE OPEN BANKING STANDARD — Version Evolution and FAPI Mandate

2.1 Version History

The Open Banking Standard is the world’s first mandated open banking API specification. Its version history reflects the evolution from basic OAuth 2.0 to the high-security FAPI 1.0 Advanced profile:

The v4.0 uplift imposed significant security enhancements:

• JARM (JWT-Secured Authorization Response Mode) — encrypts the authorisation response to prevent interception.

• nbf (not-before) claim ≤90 seconds in client assertions.

• exp (expiry) claim ≤120 seconds from issue.

• mTLS certificate expiry ≤365 days, with automated renewal every 90 days recommended.

2.2 FAPI 1.0 Advanced — The Mandatory Security Profile

FAPI (Financial-grade API) 1.0 Advanced is the security foundation for open banking standards worldwide. It has been adopted by:

• UK Open Banking Standard (mandatory)

• Australia’s CDR Information Security Profile

• Brazil’s Open Finance security profile

• Saudi Arabia’s Open Banking Framework

Key FAPI 1.0 Advanced requirements beyond standard OAuth 2.0:

1. JARM (JWT-Secured Authorization Response Mode) — the authorisation response must be a signed and optionally encrypted JWT.

2. Client Assertion — the TPP must present a JWT client assertion with nbf ≤90 seconds and exp ≤120 seconds.

3. PKCE (Proof Key for Code Exchange) — mandatory for all authorisation code flows.

4. mTLS — mandatory for all token endpoints and resource endpoints.

5. Scope validation — the ASPSP must validate that the requested scope matches the TPP’s registered capabilities.

2.3 The Read/Write API Standard — Core Endpoints

The Open Banking Standard defines comprehensive Read/Write APIs for:

Account Information (AISP) :

• POST /account-requests — initiate a request to access account data

• GET /account-requests/{id} — retrieve the status of the request

• GET /accounts — list accounts after consent granted

• GET /accounts/{id}/transactions — fetch transaction history

• GET /accounts/{id}/balances — fetch current balances

• GET /accounts/{id}/direct-debits — fetch direct debit mandates

• GET /accounts/{id}/standing-orders — fetch standing order instructions

Payment Initiation (PISP) :

• POST /payments — initiate a single immediate payment

• GET /payments/{id} — check payment status

• POST /domestic-payment-consents — create a consent for payment (pre-authorisation)

• GET /domestic-payment-consents/{id} — retrieve consent status

Variable Recurring Payments (VRP) :

• POST /vrp/consents — create a VRP consent

• GET /vrp/consents/{id} — retrieve consent status

• POST /vrp/payments — initiate a VRP payment (sweeping)

• GET /vrp/payments/{id} — check VRP payment status

PART 3: VARIABLE RECURRING PAYMENTS (VRP) — The Sweeping Mandate

3.1 What Are VRPs?

Variable Recurring Payments (VRPs) are a CMA-mandated mechanism that enables automated sweeping between accounts. Unlike fixed recurring payments (e.g., a monthly subscription), VRPs allow:

• Variable amounts — the amount can change with each sweep.

• Automated scheduling — sweeps can occur weekly, monthly, or on demand.

• Consent management — the PSU grants consent once, and the TPP executes sweeps within the consent parameters.

The CMA mandated that the CMA9 must offer open access to the VRP API for sweeping—enabling fintechs to build automated savings, debt management, and cash flow optimisation tools.

3.2 VRP Consent and Sweeping Flow

+-----------------------------------------------------------------------+
|              VRP CONSENT & SWEEPING SEQUENCE (UK V4.0)                 |
+-----------------------------------------------------------------------+
|                                                                        |
|  PSU          TPP (VRP init)      ASPSP (Bank)       Consent UI       |
|   |               |                   |                   |            |
|   |--(1) Auth---->|                   |                   |            |
|   |   request      |                   |                   |            |
|   |               |--(2) POST /vrp/consents               |            |
|   |               |  Headers:                            |            |
|   |               |  x-idempotency-key: consent-001     |            |
|   |               |  x-fapi-financial-id: OBIE-UK-123  |            |
|   |               |  Body: {                             |            |
|   |               |    "recurring_indicator": true,      |            |
|   |               |    "max_amount": 500.00,             |            |
|   |               |    "frequency": "weekly",            |            |
|   |               |    "start_date": "2026-08-10",       |            |
|   |               |    "end_date": "2027-08-10",         |            |
|   |               |    "payee": {                        |            |
|   |               |      "name": "Savings Account",      |            |
|   |               |      "iban": "GB00..."               |            |
|   |               |    }                                 |            |
|   |               |  }                                   |            |
|   |               |                   |                   |            |
|   |               |                   |--(3) Create CT--->|            |
|   |               |                   |  (Consent Token)  |            |
|   |               |                   |  Expiry: 90 days  |            |
|   |               |                   |                   |            |
|   |               |<-(4) Auth URL-----|                   |            |
|   |               |  (redirect PSU)   |                   |            |
|   |               |                   |                   |            |
|   |<-(5) Redirect--|                   |                   |            |
|   |   to Auth URL  |                   |                   |            |
|   |               |                   |                   |            |
|   |--------------(6) SCA challenge---------------------->|            |
|   |               |                   |                   |            |
|   |  (PSU sees:   |                   |                   |            |
|   |   "Allow       |                   |                   |            |
|   |    Savings     |                   |                   |            |
|   |    App to      |                   |                   |            |
|   |    sweep up    |                   |                   |            |
|   |    to £500     |                   |                   |            |
|   |    weekly?")   |                   |                   |            |
|   |               |                   |                   |            |
|   |<-(7) Approve--|                   |                   |            |
|   |   (biometric) |                   |                   |            |
|   |               |                   |<-(8) CT approved--|            |
|   |               |                   |  (consent stored) |            |
|   |               |                   |                   |            |
|   |               |<-(9) Access token-|                   |            |
|   |               |   (with VRP scope)|                   |            |
|   |               |                   |                   |            |
|   |  (Weekly sweep runs automatically)                   |            |
|   |               |                   |                   |            |
|   |--(10) Sweep->|                   |                   |            |
|   |   (weekly)    |--(11) POST /vrp/payments              |            |
|   |               |  Headers:                            |            |
|   |               |  x-idempotency-key: sweep-2026-08-17|            |
|   |               |  Body: {                             |            |
|   |               |    "consent_id": "ct-001",           |            |
|   |               |    "amount": 100.00,                 |            |
|   |               |    "reference": "Weekly sweep"       |            |
|   |               |  }                                   |            |
|   |               |                   |--(12) Execute---->|            |
|   |               |                   |  (no SCA because  |            |
|   |               |                   |   consent active) |            |
|   |               |                   |                   |            |
|   |               |<-(13) 201 Created--|                   |            |
|   |               |  Location: /vrp/  |                   |            |
|   |               |   payments/sweep- |                   |            |
|   |               |   001             |                   |            |
|   |               |                   |                   |            |
|   |<-(14) Notify--|                   |                   |            |
|   |  "£100 swept  |                   |                   |            |
|   |   to Savings" |                   |                   |            |
+-----------------------------------------------------------------------+

3.3 VRP Consent Parameters

Re-authorisation: VRP consent must be re-authorised every 90 days (unless the PSU revokes earlier). The TPP must query the ASPSP’s /vrp/consents/{id} endpoint every 12 hours to detect expiry before the sweeping batch runs.

PART 4: COMPLIANCE, ENFORCEMENT, AND OPERATIONAL RISK

4.1 API Throughput Baseline — 25 RPS per TPP

The OBL MI reporting requirements specify the following API throughput baselines for CMA9 banks:

Failure to sustain these rates triggers Article 58 directions—the CMA can compel the bank to upgrade infrastructure, add capacity, or face public reprimand.

4.2 The OBIE Governance Structure

+-----------------------------------------------------------------------+
|                   OBIE GOVERNANCE STRUCTURE (2026)                     |
+-----------------------------------------------------------------------+
|                                                                        |
|                         +---------+                                   |
|                         |   CMA   |  (Regulatory oversight)           |
|                         +----+----+                                   |
|                              |                                        |
|                              v                                        |
|                    +-----------------+                               |
|                    | Implementation  |  (Independent oversight)      |
|                    |    Trustee      |  - Reports to CMA             |
|                    |                 |  - Can compel OBL changes     |
|                    +--------+--------+                               |
|                             |                                        |
|                             v                                        |
|                   +---------------------+                            |
|                   |  Open Banking Ltd   |  (OBIE trading name)       |
|                   |  (Implementation    |  - Funded by CMA9         |
|                   |   Entity)           |  - Maintains standards    |
|                   +----------+----------+                            |
|                              |                                       |
|         +--------------------+--------------------+                 |
|         |                    |                    |                 |
|         v                    v                    v                 |
|   +----------+        +----------+        +----------+             |
|   | Standards|        | Directory|        |  MI Data |             |
|   |  Board   |        |  Service |        |  Reports |             |
|   +----------+        +----------+        +----------+             |
|   | - Maintains |     | - TPP      |     | - Collects |             |
|   |   API spec  |     |   registration|   |   performance|          |
|   | - Approves |     | - Certificate |  |   metrics  |             |
|   |   changes  |     |   management  |  | - Publishes|             |
|   +----------+        +----------+        +----------+             |
+-----------------------------------------------------------------------+

4.3 Operational Risk Scenarios

Scenario 1 — API Throughput Failure: A CMA9 bank’s API gateway cannot sustain 25 RPS during peak hours. TPPs experience 5-second timeouts. Payment initiations fail. The CMA issues an Article 58 direction, forcing the bank to upgrade infrastructure within 30 days—costing £5M in emergency capacity.

Scenario 2 — FAPI Non-Compliance: A CMA9 bank fails to implement the mandatory FAPI 1.0 Advanced uplift by Q1 2023. The TPP’s client assertions are rejected because the nbf claim exceeds 90 seconds. The TPP complains to OBIE. The CMA investigates and imposes a public reprimand—damaging the bank’s reputation and eroding TPP trust.

Scenario 3 — VRP Consent Expiry: A TPP fails to implement consent health checks. A VRP consent expires at 90 days, but the TPP continues to submit sweeping payments. The ASPSP rejects the payments with 403 Forbidden. The PSU’s savings account is not funded. The TPP loses the customer and faces a complaint to the Financial Ombudsman.

CLOSING — OPERATIONAL RISK OF CMA NON-COMPLIANCE

The CMA Order 2017 is not a suggestion—it is a legally binding direction with real enforcement teeth. The certified Open Banking practitioner must internalise that every API endpoint they design for a UK bank must satisfy the OBIE standard, must implement FAPI 1.0 Advanced, and must sustain 25 RPS during peak hours.

Key takeaways:

• The CMA Order 2017 mandates the world’s first open banking API standard.

• Articles 10, 12, 13, 14, 57, and 58 define the legal obligations.

• FAPI 1.0 Advanced is mandatory for UK Open Banking v4.0.

• VRP enables automated sweeping with 90-day consent re-authorisation.

• API throughput baseline: 25 RPS per TPP during peak.

• Non-compliance triggers Article 58 directions—potentially forcing infrastructure re-engineering at the bank’s expense.

Transition to Lesson 1.3: Now that you have mastered the UK’s CMA framework, we cross the globe to Australia’s Consumer Data Right (CDR)—an economy-wide data portability scheme that extends beyond banking into energy, telecommunications, and beyond. You will learn the CDR’s accreditation requirements, the role of the ACCC and OAIC, and the technical standards that make CDR the most ambitious data-sharing regime in the world.