Products
© Fiskil 2026. All rights reserved.
Technical Comparison
Updated 26 January 2026
For years, screen scraping (using consumer credentials to log into bank websites) was the primary method for third parties to access financial data. Open banking APIs represent a fundamental shift, providing authorized, secure access without credential sharing. This comparison examines both approaches across technical, security, and business dimensions to understand why regulatory frameworks worldwide are phasing out screen scraping.
Standardized, regulated APIs provided by banks enabling authorized third-party data access through OAuth-based consent.
Official SourceLegacy method where consumers share login credentials, allowing third parties to programmatically access bank websites.
Official SourceSecurity: APIs use OAuth tokens; scraping requires credential sharing
Revocation: APIs enable instant revocation; scraping requires password change
Reliability: APIs contractually reliable; scraping breaks with site changes
Granularity: APIs allow specific data access; scraping gives full account access
Regulatory: APIs required by law; scraping being phased out
Performance: APIs fast (~500ms); scraping slow (5-30 seconds)
Consent: APIs have formal consent frameworks; scraping has none
Data Quality: APIs provide structured data; scraping parses HTML
Criterion | APIs | Screen Scraping |
|---|---|---|
Security Model | OAuth 2.0 authorization - credentials never shared with third parties. Token-based access. | Consumers share username and password with third party. Full account access. |
→ APIs fundamentally more secure by eliminating credential sharing. | ||
Credential Storage | Third party never receives or stores bank credentials | Third party must store consumer credentials (often encrypted) |
→ Credential storage creates breach risk and compliance challenges. | ||
Access Control | Granular - consumers authorize specific data types only | All-or-nothing - full account access with consumer credentials |
→ APIs enable precise permission control; scraping provides full access. | ||
Revocation | Instant - consumers revoke tokens through bank or third-party dashboards | Consumer must change password at bank to revoke access |
→ API revocation immediate and user-friendly; scraping requires password change. | ||
Consent Management | Explicit consent with duration limits, purpose specification, audit trails | No formal consent mechanism beyond credential sharing |
→ APIs have regulatory-compliant consent; scraping has no consent framework. | ||
Data Format | Structured JSON/XML with standardized schemas | Unstructured HTML requiring parsing and interpretation |
→ API data is machine-readable and consistent; scraped data requires parsing. | ||
Reliability | High - banks must meet uptime SLAs (typically 99.5%+) | Low - breaks when banks update websites, CAPTCHAs, or security measures |
→ APIs contractually reliable; scraping fragile and breaks frequently. | ||
Data Freshness | Real-time or near-real-time updates | Depends on scraping frequency; often delayed |
→ Both can provide recent data, but APIs designed for real-time access. | ||
Performance | Fast - optimised APIs with caching, typically <500ms response | Slow - must navigate full website UI, often 5-30 seconds |
→ APIs dramatically faster than simulating browser sessions. | ||
Bank Detection Risk | No risk - authorized access that banks expect and support | High risk - banks often block suspected scraping activity |
→ Scraping may violate bank ToS; APIs are contractually permitted. | ||
Multi-Factor Auth | Handled by bank during OAuth flow, transparent to third party | Blocks scraping or requires complex MFA automation |
→ APIs handle MFA natively; scraping broken by MFA requirements. | ||
Regulatory Status | Required by CDR, PSD2, Section 1033, UK OB. Fully compliant. | Being phased out globally. May violate regulations in some jurisdictions. |
→ APIs are regulatory requirement; scraping being prohibited. | ||
Liability Model | Clear liability framework - banks and third parties have defined responsibilities | Unclear liability - credential sharing complicates fraud attribution |
→ API liability well-defined; scraping creates liability ambiguity. | ||
Development Effort | Single integration per regulatory framework (CDR, PSD2, etc.) | Custom scraper per bank, frequent maintenance for website changes |
→ APIs scale efficiently; scraping requires per-bank development. | ||
Cost Structure | Potential API usage fees (though CDR prohibits this); lower maintenance | No direct fees but high maintenance costs for scraper updates |
→ API costs more predictable; scraping has hidden maintenance costs. | ||
Both enable third-party access to consumer financial data
Both require consumer authorization (though mechanisms differ)
Both can access similar data types (accounts, transactions, balances)
Both face fraud detection and monitoring challenges
Both require secure transmission (HTTPS)
Open banking APIs represent a fundamental improvement over screen scraping across every dimension: security, reliability, regulatory compliance, performance, and consumer protection. The global shift from scraping to APIs is not just regulatory mandates—it's a recognition that credential-based access is inherently insecure and unreliable. While screen scraping was necessary in the absence of bank APIs, open banking frameworks (CDR, PSD2, Section 1033, UK OB) have made it obsolete. Organisations still using screen scraping should prioritise migration to API-based access for security, compliance, and business sustainability.
Regulatory Comparison
Australia's Consumer Data Right (CDR) and the United States' Section 1033 (CFPB final rule) represent two distinct approaches to consumer financial data access. While both enable consumers to share their data with third parties, they differ significantly in regulatory philosophy, technical prescriptiveness, and implementation approach. This comparison examines both frameworks to help organisations understand compliance requirements in each jurisdiction.
Regulatory Comparison
Australia's Consumer Data Right (CDR) and Europe's Payment Services Directive 2 (PSD2) represent two different regulatory approaches to open banking. PSD2, implemented across the European Union, focuses on payment services and competition in financial services. CDR, Australia's economy-wide framework, takes a broader data portability approach. This comparison examines both frameworks across regulatory, technical, and implementation dimensions.
Our team can help you navigate regulatory compliance and determine what you need to meet your open banking obligations.
Products
© Fiskil 2026. All rights reserved.