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.
It depends on jurisdiction. Screen scraping is being phased out under Section 1033 in the US once APIs are available. In the EU under PSD2, banks cannot contractually prohibit scraping, but APIs are strongly encouraged. In Australia under CDR, APIs replace any need for scraping. Many banks' Terms of Service prohibit unauthorized screen scraping.
Screen scraping emerged because banks did not provide APIs for third-party data access. It was the only method for consumers to aggregate their financial accounts or use financial management tools. Open banking regulations were created specifically to replace screen scraping with secure, authorized API access.
Temporarily, yes. Section 1033 allows screen scraping during API transition periods. However, long-term coexistence is unlikely as regulations phase out scraping and banks implement security measures (MFA, bot detection) that break scraping.
Initially, perhaps. A screen scraper can be built quickly. However, ongoing maintenance costs (breaking website changes, CAPTCHA handling, MFA complications) far exceed API integration costs. APIs are faster to implement at scale across multiple banks.
Screen scraping often breaks with MFA requirements. Automating MFA (SMS codes, push notifications, hardware tokens) is technically difficult and may violate security policies. This is one reason regulators mandate APIs—MFA is essential for security but incompatible with scraping.
Consumers overwhelmingly prefer APIs when educated about the security differences. APIs don't require sharing passwords, enable granular control, and allow easy revocation. Consumer surveys consistently show preference for OAuth-based flows over credential sharing.
Technically yes, through CAPTCHAs, rate limiting, IP blocking, and behavioral analysis. However, in some jurisdictions (EU under PSD2), banks cannot contractually prohibit scraping. With open banking APIs, banks are moving away from "blocking" to "replacing" scraping with superior API alternatives.
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.