Open Banking Security 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 Recurring Payments (VRP) and long-lived authorisations with appropriate safeguards. Customer Authentication User Experience Standards must (a) implement consistent + accessible + multilingual UX per applicable scheme requirements + (b) minimise friction without compromising security + (c) test with diverse populations + (d) provide customer notification of third-party access including transactions initiated by TPPs.
Maintained by Gerard Blokdyk·Verified against the published standard ·Control text last updated
What else in your programme already covers this
This control maps to 152 controls across 88 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
NIST-CSF-DE.AE-08 Incidents are declared when adverse events meet the defined incident criteria
NIST-CSF-PR.AA-05 Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties