Skip to content

Evidence request lists

Open Banking Security

Evidence request list. 8 controls, 8 carrying auditor artefact guidance. Generated from the compliance knowledge graph on 12 September 2026. Published by The Art of Service.

Data Minimisation and Localisation

OPENBANK-5
Data Minimisation, Scope Enforcement, Localisation, Cross-Border Transfers

Apply data minimisation + scope enforcement + localisation + cross-border transfers per applicable regulation. Data Minimisation and Scope Enforcement must (a) enforce OAuth scope checking at every API endpoint + (b) return only data within authorised scope + (c) prevent broad consent abuse + (d) align with applicable data minimisation principle (UK GDPR + EU GDPR + national equivalents + sector-specific). Data localisation and cross-border transfers must (a) honor data residency requirements per applicable regulation (Brazil LGPD + China PIPL + Russia + UAE + KSA + India + Vietnam + similar), (b) implement transfer safeguards per applicable mechanism (SCCs + BCRs + adequacy + consent + regulator approval), (c) maintain transfer impact assessment for sensitive transfers. Sanctions and AML integration must (a) integrate open banking transactions with sanctions screening + AML monitoring +

Artefacts an auditor will ask for
  • Open Banking Security compliance evidence for OPENBANK-5
Where this commonly fails
  • compliance nominal not operational

FAPI 2.0 Conformance

OPENBANK-1
FAPI 2.0 Security Profile and OpenID Foundation Conformance

Conform to OpenID Foundation Financial-grade API (FAPI) 2.0 Security Profile per FAPI 2.0 Security Profile and FAPI 2.0 Message Signing specifications administered by the OpenID Foundation FAPI Working Group. FAPI 2.0 (final 2024) replaces FAPI 1.0 with simplified + stronger requirements + including mandatory PKCE + Pushed Authorisation Requests (PAR) + sender-constrained tokens + JARM. Conformance must (a) implement Authorisation Server and Client per FAPI 2.0 with all MUST and SHOULD requirements documented + (b) participate in OpenID Foundation FAPI conformance certification programme + maintain current conformance status, (c) align with national open banking schemes (UK OBL + Brazil + Australia CDR + Saudi SAMA + others) where applicable, (d) maintain regression testing on Authorisation Server + Client implementations during release cycles + (e) integrate with broader API security pr

Artefacts an auditor will ask for
  • Open Banking Security compliance evidence for OPENBANK-1
Where this commonly fails
  • compliance nominal not operational

Fraud + TRA + Rate Limiting + Sandbox

OPENBANK-6
Fraud Detection, Transaction Risk Analysis, Rate Limiting, Sandbox

Operate fraud detection + Transaction Risk Analysis + rate limiting + sandbox per scheme requirements. Fraud Detection and Transaction Risk Analysis must (a) implement real-time fraud detection at authorisation + initiation + completion + (b) consider device + behavioural + geographic + transaction pattern signals + (c) integrate with TRA for SCA exemption decisions where applicable + (d) maintain false positive + false negative metrics + tuning. API Rate Limiting and Throttling Controls must (a) implement rate limiting per TPP + per customer + per scope + (b) prevent abuse + DoS + scraping + (c) align with scheme-defined limits + (d) provide back-off signals + retry-after guidance. Sandbox Parity and Testing Facilities must (a) maintain sandbox environment with production-grade API behaviour + (b) provide TPP testing capability + (c) maintain documentation + sample data + onboarding sup

Artefacts an auditor will ask for
  • Open Banking Security compliance evidence for OPENBANK-6
Where this commonly fails
  • compliance nominal not operational

Incident + BCM

OPENBANK-8
Incident Detection, Response, Customer Notification, Post-Incident Review, BCM

Operate incident detection + response + customer notification + post-incident review + BCM per scheme + applicable regulation. Incident detection and classification must (a) implement SIEM + EDR + fraud detection + with open banking-aware correlation rules + (b) classify incidents per scheme requirements (cyber + operational + customer impact + payment fraud + similar) + (c) integrate with broader security operations. Incident response and containment must (a) maintain IR plan with open banking scenarios (TPP compromise + API abuse + customer credential theft + transaction fraud + scheme infrastructure attack), (b) coordinate with scheme operator + national CERT + payment brand + regulator per applicable obligation. Regulatory reporting requirements must (a) report incidents within scheme + regulatory timeframes (varying 2 hours + 4 hours + 24 hours + 72 hours + 5 days per scheme + incid

Artefacts an auditor will ask for
  • Open Banking Security compliance evidence for OPENBANK-8
Where this commonly fails
  • compliance nominal not operational

Logging + Reporting + SLA

OPENBANK-7
Logging, Monitoring, Regulatory Reporting, SLA, Availability

Operate logging + monitoring + regulatory reporting + SLA + availability per scheme + applicable regulation. Logging Monitoring and Reporting to Regulators must (a) collect comprehensive API audit logs covering authentication + authorisation + transactions + admin actions + (b) maintain regulator reporting per scheme requirements (UK OBIE + EU PSD2/3 incident reporting + Brazilian Open Finance + Australian CDR + similar), (c) report incidents + SLA breaches + customer complaints + fraud metrics + (d) integrate with broader regulatory reporting function. Service Level Agreement and Availability must (a) maintain scheme-required SLAs (typically 99.5%+ availability for in-scope APIs) + (b) monitor + measure + report SLA conformance + (c) maintain incident management + remediation + customer notification + (d) align with broader BCM + DR programme. Communication and escalation procedures mus

Artefacts an auditor will ask for
  • Open Banking Security compliance evidence for OPENBANK-7
Where this commonly fails
  • compliance nominal not operational

SCA + Consent + UX

OPENBANK-2
Strong Customer Authentication (SCA), Consent Lifecycle, and Customer UX

Implement Strong Customer Authentication + Consent Lifecycle + Customer UX per applicable open banking regulation (UK FCA PSR + EU PSD2 + EU PSD3 + Australian CDR + Brazilian Open Finance + similar). SCA must (a) implement multi-factor authentication using two or more independent elements from knowledge + possession + inherence per applicable regulation + (b) implement dynamic linking for payment authentication + (c) maintain exemptions where applicable (low-value + trusted beneficiary + recurring transaction + corporate + risk-based) per regulation, (d) integrate with broader identity and access management. Consent and authorisation lifecycle must (a) capture explicit + informed consent for data sharing + payment initiation + with clear scope + duration + data categories + (b) provide consent management dashboard for customer + with revocation + audit trail + (c) implement Variable Recu

Artefacts an auditor will ask for
  • Open Banking Security compliance evidence for OPENBANK-2
Where this commonly fails
  • compliance nominal not operational

TPP Onboarding

OPENBANK-4
Third Party Provider (TPP) Onboarding, Directory Integration, Due Diligence

Operate Third Party Provider onboarding + directory integration + due diligence per national scheme + applicable regulation. Third Party Provider Onboarding must (a) verify TPP authorisation status via national directory (UK OBIE Directory + EU eIDAS + Brazil + Australian Accreditation + SAMA + similar), (b) maintain TPP eligibility verification ongoing through directory checks, (c) handle TPP certificate management + key rotation + revocation + (d) coordinate with TPP for testing + onboarding + change management. Due diligence + onboarding must (a) conduct TPP cybersecurity due diligence + (b) verify regulatory authorisation + insurance + operational capability + (c) document onboarding decision + ongoing oversight obligations. Concentration risk management must (a) monitor TPP concentration + critical-service identification + alternative arrangements + (b) coordinate with regulator on

Artefacts an auditor will ask for
  • Open Banking Security compliance evidence for OPENBANK-4
Where this commonly fails
  • compliance nominal not operational

mTLS + Signing + Keys

OPENBANK-3
Mutual TLS, Token Binding, Request Signing (JWS), Key Management

Implement mutual TLS + token binding + JWS signing + key management per FAPI 2.0 + national scheme requirements. mTLS for Client Authentication and Token Binding must (a) use certificate-based mutual authentication between AS + Client + (b) bind tokens to client certificate via OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens (RFC 8705), (c) maintain certificate lifecycle including provisioning + renewal + revocation + with directory integration. Request signing with JSON Web Signatures must (a) sign requests per JAR (JWT-Secured Authorization Request) + JARM (JWT Authorization Response Mode) + Pushed Authorization Request, (b) maintain JWKS endpoint + signing key rotation. Key Management for Signing and Encryption must (a) maintain dedicated signing + encryption keys per FAPI 2.0 + national scheme + (b) use HSM where appropriate + (c) implement key rotation

Artefacts an auditor will ask for
  • Open Banking Security compliance evidence for OPENBANK-3
Where this commonly fails
  • compliance nominal not operational
Assembled from the framework's own control set. Every line traces to a control in the graph, so this pack is regenerated rather than written, and stays current as the graph does.

Assembled from the framework’s own control set, so this list is regenerated rather than written and stays current as the graph does. See the Open Banking Security framework page.