Open Banking / PSD2 / Open Finance attacks — FAPI (Financial-grade API), OpenID Connect for Financial APIs, OAuth2 PKCE, Strong Customer Authentication (SCA) bypass, AIS/PIS/CBPII API abuse, payment redirection, consent manipulation. Covers UK Open Banking, US FDX, Brazil Open Finance, India Account Aggregator, Singapore MAS APIX, Australia CDR. Includes 2024-2025 incidents (Token Hijacking, IdOR on AIS endpoints, PIS redirect manipulation).
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Open Banking / PSD2 / Open Finance attacks — FAPI (Financial-grade API), OpenID Connect for Financial APIs, OAuth2 PKCE, Strong Customer Authentication (SCA) bypass, AIS/PIS/CBPII API abuse, payment redirection, consent manipulation. Covers UK Open Banking, US FDX, Brazil Open Finance, India Account Aggregator, Singapore MAS APIX, Australia CDR. Includes 2024-2025 incidents (Token Hijacking, IdOR on AIS endpoints, PIS redirect manipulation).
{"domain":"fintech-banking","tool_count":13,"guide_count":2,"mitre":"TA0001-Initial Access, TA0006-Credential Access, TA0009-Collection, T1552-Unsecured Credentials, T1550-Use Alternate Authentication Material, T1185-Man in the Browser","last_reviewed":"2026-07-26"}
Open Banking Attack Skill
Red-team operations against Open Banking / Open Finance infrastructure — the modern OAuth2/FAPI stack that powers UK Open Banking, PSD2, Brazil Open Finance, US FDX, India Account Aggregator, and more. Targets: TPPs (Third-Party Providers), banks (ASPSPs), consent APIs, and the customer journey from consent → data access → payment initiation.
Summary
Open Banking (formerly PSD2) is the API-driven banking standard that lets customers share account data with Third-Party Providers (TPPs) and initiate payments via API. As of 2024-2026:
UK Open Banking: ~10M active users, 400+ regulated TPPs
EU PSD2/PSD3: every EU bank exposes AIS/PIS APIs
Brazil Open Finance: 800M+ API calls/month
India Account Aggregator: 1.4B+ AA transactions
US FDX: 200M+ accounts accessible via FDX API
Singapore MAS APIX: cross-border pilots
Australia CDR: Consumer Data Right, mandatory for banks
# Discover Open Banking endpoints via well-known
curl -s https://bank.example.com/.well-known/openid-configuration | jq .
# Output includes:# - authorization_endpoint# - token_endpoint# - userinfo_endpoint# - jwks_uri# - scopes_supported# - code_challenge_methods_supported (should include S256 for FAPI)# - request_object_signing_alg_values_supported (should include PS256)# Check FAPI profile support
curl -s https://bank.example.com/.well-known/openid-configuration | jq '.scopes_supported'# UK Open Banking: well-known URLs follow pattern
curl -s https://matls-auth.example.com/.well-known/openid-configuration
curl -s https://api.example.com/open-banking/v3.1/aisp/accounts
Phase 2 — TPP Registration
To legitimately test Open Banking, you need a TPP identity:
Register sandbox account on bank's developer portal
Generate eIDAS QWAC + QSeal certs (sandbox)
Register OAuth2 client (TPP onboarding)
Get client_id, client_secret, SSA (Software Statement Assertion)
# Register TPP (UK OBIE pattern)
curl -X POST https://register.example.com/v1.1/register/ \
-H 'Content-Type: application/jwt' \
-d @ssa.jwt
Phase 3 — Consent Flow Testing
Test the AIS consent flow:
AIS client creates consent via API
Bank returns consent ID
Customer redirected to bank for SCA
Customer approves consent
Bank returns authorization code
TPP exchanges code for access token
TPP uses token to read accounts
Phase 4 — SCA Bypass
Try to skip SCA:
Contactless exemption abuse (low-value payment without SCA)
Trusted beneficiary list abuse
Corporate payment SCA exemption abuse
Redirect URI manipulation to capture code without SCA completion
Phase 5 — AIS Abuse
With valid AIS consent:
Enumerate account IDs (IdOR)
Read transactions beyond consent scope
Read balances on accounts not in consent
Read beneficiary lists, standing orders, direct debits
Phase 6 — PIS Abuse
With PIS consent:
Initiate payment to attacker-controlled creditor
Modify debtor account after consent
Modify amount after consent
Chain to multiple payments
Phase 7 — Token Abuse
Test access token security:
mTLS enforcement (does token work without cert?)
DPoP enforcement (does token work without DPoP proof?)
Token replay across endpoints
Refresh token abuse
Practical Steps
Step A — Discover OIDC config
curl -s https://auth.example.com/.well-known/openid-configuration | jq . > oidc-config.json
# Inspect
jq '. | keys' oidc-config.json
jq '.request_object_signing_alg_values_supported' oidc-config.json
# Expect: ["PS256", "ES256"] for FAPI# If "none" — FAPI not enforced
jq '.code_challenge_methods_supported' oidc-config.json
# Expect: ["S256"] for FAPI# If "plain" — PKCE downgrade possible
jq '.scopes_supported' oidc-config.json
# Expect: openid, accounts, payments, fundsconfirmations
Step B — Test PAR (Pushed Authorization Requests)
# FAPI requires PAR (pushed authorization)
curl -sk -X POST https://auth.example.com/par \
-H 'Content-Type: application/x-www-form-urlencoded' \
--cert client.crt --key client.key \
-d 'response_type=code&client_id=REPLACE_WITH_YOUR_CLIENT_ID&redirect_uri=https://tpp.example.com/cb&scope=accounts&code_challenge=REPLACE_WITH_YOUR_CHALLENGE&code_challenge_method=S256&state=abc123'# Returns: request_uri# If PAR not enforced — old OAuth2 flow with request object still allowed (downgrade)
Step C — Test mTLS sender-constrained tokens
# Get token with mTLS cert
TOKEN=$(curl -sk -X POST https://auth.example.com/token \
--cert client.crt --key client.key \
-d 'grant_type=authorization_code&code=...&redirect_uri=...&client_id=...' | jq -r .access_token)
# Use token WITH mTLS cert
curl -sk https://api.example.com/open-banking/v3.1/aisp/accounts \
-H "Authorization: Bearer $TOKEN" \
--cert client.crt --key client.key
# Now try WITHOUT mTLS cert (token should fail)
curl -sk https://api.example.com/open-banking/v3.1/aisp/accounts \
-H "Authorization: Bearer $TOKEN"# If second succeeds — mTLS not enforced, token replayable
Step D — AIS IdOR
# With consent for account A
TOKEN=...
ACCOUNT_A=REPLACE_WITH_YOUR_ACCOUNT_A_ID
# Try to access account B (not in consent)
ACCOUNT_B=REPLACE_WITH_YOUR_ACCOUNT_B_ID
curl -sk "https://api.example.com/open-banking/v3.1/aisp/accounts/$ACCOUNT_B/transactions" \
-H "Authorization: Bearer $TOKEN" \
--cert client.crt --key client.key
# If 200 OK — IdOR, account B accessible# If 403 — proper isolation
# Customer uses a2a payment (e.g., pay small business via Open Banking)# Customer's banking app receives redirect from TPP# Intercept via mitmproxy
mitmproxy --mode regular
# Or Burp Suite# Capture a2a redirect# Look for: # GET https://tpp.example.com/return?code=abc&state=xyz# Customer taps "Pay" in banking app → bank sends auth code to TPP# If redirect can be replayed → fraudulent payment
Defense Perspective
Detection
ASPSP (Bank)
Audit consent creation / approval / usage
Alert on AIS read beyond consent scope (multi-account reads)
Alert on PIS to new creditor (above customer baseline)
Alert on rapid consent creation across many customers (TPP scanning)
Detect mTLS-mismatched token use (token from cert A used with cert B)
TPP
Audit customer consent approval / withdrawal
Detect unexpected eIDAS cert use (cert from different TPP)
