Open Banking
System providing third-party access to financial data through APIs.
Why it matters
Open banking matters because it moves bank connectivity from screen scraping and bilateral integrations toward standardized consent, stronger security controls, auditable data access, and new account-to-account payment flows.
How it works
In practice, the user grants consent, the third party authenticates and requests access through the standard interface, the account provider validates the request, and data or payment instructions move within the agreed permission scope.
Risks and pitfalls
The main error is to ignore consent scope or role boundaries. Account information, payment initiation, confirmation of funds, and recurring permission models carry different risks and should not be described as one generic API access pattern.
Regional notes
For BIST and MOEX comparisons, open banking should be mapped to local payment-services regulation, bank API maturity, customer-authentication norms, and whether account-to-account payments have a reliable commercial rail.
Related terms
Compare with
Banking-as-a-ServiceBuild from
APIPrimary sources
Open Banking UK
2026-03-15Open Banking UK: API standards
Primary source for open banking permissions and recurring payment rails.
European Banking Authority
2026-03-15European Banking Authority: Strong Customer Authentication
Primary source for SCA and PSD2 compliance context.
SWIFT
2026-03-15SWIFT: ISO 20022 migration
Primary source for ISO 20022 and messaging standards.
Reviewed
5/4/2026
Common questions
What does Open Banking mean?
System providing third-party access to financial data through APIs.
Why does Open Banking matter in fintech?
Open banking matters because it moves bank connectivity from screen scraping and bilateral integrations toward standardized consent, stronger security controls, auditable data access, and new account-to-account payment flows.
What risks should teams watch with Open Banking?
The main error is to ignore consent scope or role boundaries. Account information, payment initiation, confirmation of funds, and recurring permission models carry different risks and should not be described as one generic API access pattern.