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
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 +
- Open Banking Security compliance evidence for OPENBANK-5
- compliance nominal not operational
FAPI 2.0 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
- Open Banking Security compliance evidence for OPENBANK-1
- compliance nominal not operational
Fraud + TRA + 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
- Open Banking Security compliance evidence for OPENBANK-6
- compliance nominal not operational
Incident + 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
- Open Banking Security compliance evidence for OPENBANK-8
- compliance nominal not operational
Logging + Reporting + SLA
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
- Open Banking Security compliance evidence for OPENBANK-7
- compliance nominal not operational
SCA + Consent + 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
- Open Banking Security compliance evidence for OPENBANK-2
- compliance nominal not operational
TPP Onboarding
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
- Open Banking Security compliance evidence for OPENBANK-4
- compliance nominal not operational
mTLS + Signing + Keys
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
- Open Banking Security compliance evidence for OPENBANK-3
- compliance nominal not operational
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.