domain-fintech:banking-apis
Guides banking API integration: Open Banking standards (PSD2, UK Open Banking, FDX), Plaid integration (Link, transactions, balance, identity), account aggregation, payment initiation (PISP), account information (AISP), BaaS platforms (Unit, Synapse, Column), and API security (mTLS, OAuth2, FAPI)...
SKILL.md
Full skill instructions
Banking APIs
When to use
- Integrating with PSD2, UK Open Banking, or FDX APIs
- Setting up Plaid Link, transaction sync, or webhook processing
- Implementing payment initiation (ACH, SEPA, Faster Payments)
- Choosing or evaluating a BaaS provider (Unit, Column)
- Securing bank API connections with mTLS, OAuth2, or FAPI
- Building account aggregation with multi-provider fallback
Core principles
- Never expose access tokens client-side — exchange public_token server-side, store encrypted
- Idempotent webhook processing — banking events are delivered at-least-once; deduplicate always
- Consent is time-limited and revocable — model consent lifecycle explicitly, not as a boolean flag
- Multi-provider normalization — abstract provider differences behind a unified internal schema
- FAPI > plain OAuth2 — financial-grade APIs require sender-constrained tokens and signed requests
Reference Files
references/open-banking-standards.md— PSD2 (Berlin Group, STET, PolishAPI), UK Open Banking, FDX, AISP consent management and data categoriesreferences/plaid-integration.md— Plaid Link flow, core products (transactions, balance, identity, auth), webhook handling, multi-provider aggregation patternsreferences/payment-initiation.md— payment types (ACH, SEPA, Faster Payments), ACH origination, payment status lifecycle, BaaS platform selection (Unit, Column)references/api-security.md— mTLS with eIDAS QWAC, OAuth 2.0 flows for banking, FAPI 1.0 Advanced requirements (JARM, PAR, DPoP, sender-constrained tokens)
