Standards & Compliance
The regulatory and standards thread running under every concept in this portal, gathered in one place. None of these are optional reading for a UK/EU banking web-auth build — they’re the floor the rest of the architecture has to clear.
PSD2 / SCA / RTS
The EU/UK Payment Services Directive 2 requires Strong Customer Authentication (SCA) — two independent factors from knowledge, possession, and inherence — for most electronic payments, detailed in the Regulatory Technical Standards (RTS). Two clauses matter most for this portal’s architecture:
- Dynamic linking — the authentication must be cryptographically bound to the specific amount and payee of this transaction, not just prove “the user is present.” This is the direct regulatory reason C2 (device binding & request integrity) exists as its own capability rather than folding into login.
- TRA (Transaction Risk Analysis) exemption — low-risk payments (below a threshold, against a low fraud-rate history) can skip SCA if the PSP’s real-time risk engine clears them. This is why C8 (risk decisioning) is load-bearing, not a nice-to-have: a good risk engine measurably reduces friction under the same regulation.
GDPR
The EU/UK General Data Protection Regulation governs any personal data processing; biometric data used for unique identification is explicitly special-category data under Article 9, requiring a stronger lawful basis (typically explicit consent or substantial public interest) than ordinary personal data. Any behavioral-biometrics signal (C7) or device fingerprinting used for fraud decisioning sits close to this line and needs a documented lawful basis, not just a privacy-policy mention.
eIDAS2 / EU Digital Identity Wallet
The EU’s revised electronic Identification, Authentication and Trust Services regulation mandates that member states offer citizens a Digital Identity Wallet for cross-border identification and attribute sharing (age, qualifications, and eventually payment credentials). Relevant here as the likely future front door for identity verification across EU banking, running in parallel to — not yet replacing — WebAuthn/passkey login.
UK DIATF / DVS
The UK’s Digital Identity and Attributes Trust Framework, implemented through the Digital Verification Services regime, certifies identity-verification providers to a common standard. Relevant to onboarding/KYC flows more than session auth, but part of the same trust-framework family this portal’s concepts sit inside.
Open Banking
The UK/EU regulatory regime requiring banks to expose account and payment data via standardized APIs to authorized third parties. FAPI 2.0 is the security profile Open Banking API access is built on — see FAPI 2.0.
OWASP ASVS / Top 10
The Application Security Verification Standard is the practical checklist this portal’s C3 (browser-side security) concepts map onto directly — CSP, SRI, cookie flags, and session management each correspond to specific ASVS requirements. The OWASP Top 10 is the higher-level “what’s actually exploited most” list; XSS and broken access control are perennial entries.
RFC index
The specific standards this portal’s demos and deep-dives implement or reference:
| RFC / Spec | Title | Where it shows up |
|---|---|---|
| RFC 6749 | OAuth 2.0 | OAuth 2.0 & OIDC |
| OIDC Core 1.0 | OpenID Connect | OAuth 2.0 & OIDC |
| RFC 7636 | PKCE | FAPI 2.0 |
| RFC 9126 | PAR (Pushed Authorization Requests) | FAPI 2.0 |
| RFC 9449 | DPoP | Sender-Constrained Tokens |
| RFC 8705 | mTLS-bound tokens | Sender-Constrained Tokens |
| RFC 9207 | iss parameter (mix-up defense) | FAPI 2.0 |
| RFC 7523 | private_key_jwt client auth | FAPI 2.0 |
| WebAuthn Level 2/3 | Public-key authentication API | WebAuthn & Passkeys |
| CTAP2 | Browser ↔ authenticator protocol | WebAuthn & Passkeys |
| W3C CSP Level 3 | Content Security Policy | CSP |
| W3C SRI | Subresource Integrity | SRI |
What to take to the client
Every concept in this portal exists because a standard, an RFC, or a regulation names the attack it closes — that’s the pitch for treating this as engineering, not a compliance checkbox. FAPI 2.0’s attacker model is the clearest example: the spec doesn’t just say “use PKCE,” it names the interception attack PKCE closes.