UK Open Banking Standard

API providers must implement Read/Write APIs enabling authorised third parties to access account information and initiate payments.

• API security standard aligned to FAPI profile
• Certificate and key inventory
• Penetration test reports against APIs
• Conformance test evidence

• Expired certificates in production
• FAPI profile partially implemented
• Rate limiting and anomaly detection thin
• Sandbox parity drift from production

CMA9 banks must provide open data APIs for products, branches, and ATM information in standardised formats.

• API security standard aligned to FAPI profile
• Certificate and key inventory
• Penetration test reports against APIs
• Conformance test evidence

• Expired certificates in production
• FAPI profile partially implemented
• Rate limiting and anomaly detection thin
• Sandbox parity drift from production

Third-party providers must register dynamically with API providers using standardised registration specifications.

• Documented procedure addressing dynamic client registration
• Evidence of executive or risk owner approval
• Operational records demonstrating execution
• Independent assurance or review report

• Procedure exists but execution inconsistent
• Owner accountability not codified
• Review cadence missed or undocumented
• Coverage gaps for in scope entities or systems

API providers must report management information on API performance, availability, and usage metrics.

• Documented procedure addressing mi reporting specification
• Evidence of executive or risk owner approval
• Operational records demonstrating execution
• Independent assurance or review report

• Procedure exists but execution inconsistent
• Owner accountability not codified
• Review cadence missed or undocumented
• Coverage gaps for in scope entities or systems

Per OBS: consent management + data sharing scopes + 90-day reauthentication + user revocation.

• OBS evidence for UKOBS-3

• FAPI 2.0 + VRP partial

Every data access request and payment initiation requires explicit, informed consent from the customer.

• Consent capture mechanism design records
• Consent log with timestamp and purpose linkage
• Withdrawal workflow evidence
• Privacy notice version aligned to consent text

• Bundled consent across distinct purposes
• Withdrawal not as easy as granting consent
• Records lack granularity per processing purpose
• Children consent thresholds not enforced

Customers must be able to provide granular, time-limited consent for each specific data request.

• Consent capture mechanism design records
• Consent log with timestamp and purpose linkage
• Withdrawal workflow evidence
• Privacy notice version aligned to consent text

• Bundled consent across distinct purposes
• Withdrawal not as easy as granting consent
• Records lack granularity per processing purpose
• Children consent thresholds not enforced

Multi-factor authentication is required for customer verification during consent and payment authorisation flows.

• Authentication standard with factor requirements
• MFA enforcement coverage report
• Privileged session policy and recording
• Phishing resistant factor rollout evidence

• MFA exemptions persist beyond review window
• SMS factor used for privileged access
• Service accounts excluded from MFA scope
• Conditional access policies overly permissive

API providers must give customers visibility and control over active consents and connected third-party providers.

• Consent capture mechanism design records
• Consent log with timestamp and purpose linkage
• Withdrawal workflow evidence
• Privacy notice version aligned to consent text

• Bundled consent across distinct purposes
• Withdrawal not as easy as granting consent
• Records lack granularity per processing purpose
• Children consent thresholds not enforced

Customers must be able to revoke consent and disconnect third-party provider access at any time.

• Consent capture mechanism design records
• Consent log with timestamp and purpose linkage
• Withdrawal workflow evidence
• Privacy notice version aligned to consent text

• Bundled consent across distinct purposes
• Withdrawal not as easy as granting consent
• Records lack granularity per processing purpose
• Children consent thresholds not enforced

Participants must enrol in the Open Banking Directory which provides trust services and identity verification.

• API security standard aligned to FAPI profile
• Certificate and key inventory
• Penetration test reports against APIs
• Conformance test evidence

• Expired certificates in production
• FAPI profile partially implemented
• Rate limiting and anomaly detection thin
• Sandbox parity drift from production

Third-party providers must complete FCA authorisation and directory enrolment before accessing Open Banking APIs.

• Governance charter or terms of reference
• Meeting minutes with decisions logged
• Accountability matrix mapping owners
• Reporting pack to board or committee

• Decisions made but not minuted
• Owners listed but not empowered
• Reporting pack lacks risk metrics
• Tone from the top not evidenced

TPPs must obtain software statement assertions from the directory for client registration with API providers.

• Documented procedure addressing software statement assertions
• Evidence of executive or risk owner approval
• Operational records demonstrating execution
• Independent assurance or review report

• Procedure exists but execution inconsistent
• Owner accountability not codified
• Review cadence missed or undocumented
• Coverage gaps for in scope entities or systems

Established processes for resolving disputes between participants in the Open Banking ecosystem.

• Complaints handling procedure
• Complaints register with categorisation
• Root cause analysis records
• Regulator reporting where required

• Categorisation inconsistent
• Root cause limited to symptoms
• SLA breaches not surfaced
• Vulnerable customer markers absent

CMA9 banks must maintain API availability at prescribed service levels with monitoring and reporting.

• AI risk and impact assessment
• Model card and datasheet
• Bias testing and mitigation evidence
• Human oversight and appeal procedure

• Risk tiering not applied at intake
• Bias testing limited to development phase
• Human oversight is theoretical not operational
• Model drift detection absent

APIs must meet performance benchmarks for response times and throughput as defined in operational guidelines.

• Documented procedure addressing performance standards
• Evidence of executive or risk owner approval
• Operational records demonstrating execution
• Independent assurance or review report

• Procedure exists but execution inconsistent
• Owner accountability not codified
• Review cadence missed or undocumented
• Coverage gaps for in scope entities or systems

The Open Banking Implementation Entity monitors CMA9 banks for conformance with the CMA Order requirements.

• Logging standard listing in-scope event types
• SIEM ingestion and retention configuration
• Alert tuning and review evidence
• Coverage gap report against the standard

• Critical assets not in SIEM coverage
• Retention period below regulatory minimum
• Alerts fired but never triaged
• Time synchronisation drift across sources

Participants must have incident management procedures for security events and service disruptions affecting Open Banking.

• Incident response plan and runbook
• Incident register with classification and timelines
• Regulator notification templates and timestamps
• Post-incident review reports with lessons learned

• Notification clock starts at detection, not initial signal
• Roles in plan diverge from actual response
• No tested tabletop within prior twelve months
• Lessons learned not fed back into controls

Per UK Open Banking Standard + OBL + FCA Handbook: Open Banking Scope and Participant Status + ASPSP + TPP registration.

• OBS evidence for UKOBS-1

• FAPI 2.0 + VRP partial

API providers and TPPs must comply with the Financial-grade API security profile for secure data exchange.

• API security standard aligned to FAPI profile
• Certificate and key inventory
• Penetration test reports against APIs
• Conformance test evidence

• Expired certificates in production
• FAPI profile partially implemented
• Rate limiting and anomaly detection thin
• Sandbox parity drift from production

All data exchange between banks and providers must use encrypted channels with modern TLS standards.

• Documented procedure addressing transport layer security
• Evidence of executive or risk owner approval
• Operational records demonstrating execution
• Independent assurance or review report

• Procedure exists but execution inconsistent
• Owner accountability not codified
• Review cadence missed or undocumented
• Coverage gaps for in scope entities or systems

Authentication and authorisation must use OAuth 2.0 and OpenID Connect protocols as specified in the security profile.

• API security standard aligned to FAPI profile
• Certificate and key inventory
• Penetration test reports against APIs
• Conformance test evidence

• Expired certificates in production
• FAPI profile partially implemented
• Rate limiting and anomaly detection thin
• Sandbox parity drift from production

Participants must use qualified certificates from the Open Banking Directory for mutual TLS authentication.

• API security standard aligned to FAPI profile
• Certificate and key inventory
• Penetration test reports against APIs
• Conformance test evidence

• Expired certificates in production
• FAPI profile partially implemented
• Rate limiting and anomaly detection thin
• Sandbox parity drift from production

Per OBS: FAPI 2.0 Security Profile Conformance + Strong Customer Authentication (SCA) + Dedicated Interface Performance and Availability + Fallback Mechanism or Exemption.

• OBS evidence for UKOBS-2

• FAPI 2.0 + VRP partial

Per OBL: Variable Recurring Payments (VRP) + commercial VRP rollout + Open Finance evolution.

• OBS evidence for UKOBS-4

• FAPI 2.0 + VRP partial