Migrate From Scraping to Open Banking: Finance & Developers Checklist

For most production use-cases in 2026, open banking APIs beat screen scraping outright, on security, reliability and compliance. The narrow exception is coverage: some smaller institutions and non-payment accounts still lack a compliant interface, which forces vendors into a supervised fallback. PSD2 and its Regulatory Technical Standards (RTS) set the legal boundary here, and the implementation detail below explains exactly where that boundary sits.

TL;DR:

• Screen scraping is increasingly unreliable and costly to maintain compared to open banking APIs, which offer higher stability and structured data.
• PSD2 and RTS regulations prohibit impersonation-based scraping for payment accounts, requiring banks to provide compliant, dedicated interfaces to third-party providers.
• Using open banking APIs with OAuth tokens enhances security, simplifies revocation, and ensures consistent data formats, unlike the fragile HTML parsing in scraping solutions.
• Coverage gaps remain for smaller banks and non-payment accounts, and access frequency is limited to four calls per 24 hours unless higher rates are contractually agreed.
• Transitioning from scraping to open banking should be phased, starting with high-volume banks, setting clear milestones, and maintaining a monitored fallback for institutions lacking compliant interfaces.

Table of Contents

• Open banking vs screen scraping: key differences at a glance
• How screen scraping works: mechanics, MFA and operational reality
• How open banking APIs work: OAuth, tokens and what developers actually get
• Security, consent and regulation: PSD2 and RTS in practice
• Operational trade-offs: reliability, coverage, cost and completeness
• Migration and hybrid patterns: a practical checklist
• Zenith’s perspective: lessons from bank sync deployments
• How Zenith handles bank sync and migration support
• Sources
• FAQ

Open banking vs screen scraping: key differences at a glance

The two methods solve the same problem, getting transaction data out of a bank, in almost opposite ways. One authenticates you with a scoped token; the other logs in pretending to be the account holder.

• Credentials vs tokens: scraping stores or replays your banking login; APIs issue a scoped access token that never touches your password.
• Consent and revocation: API consent is granted and withdrawn through the bank’s own interface; scraping consent is buried in a vendor’s terms and harder to revoke cleanly.
• Reliability and maintenance: scrapers break every time a bank redesigns its login page; APIs follow a versioned contract that rarely changes without notice.
• Data format: APIs return structured JSON with defined fields; scraping yields raw HTML that must be parsed and re-parsed after every UI update.
• Performance and failure modes: APIs typically fail with a clear error code; scraping tends to fail silently or return partial, malformed data.

The pattern holds across almost every comparison of bank feeds vs CSV-style manual exports too: structured, contract-based data beats anything scraped or hand-exported, mainly because someone else is responsible for keeping the format stable.

How screen scraping works: mechanics, MFA and operational reality

Screen scraping is exactly what it sounds like: software logs into your online banking portal using your actual credentials, then reads the rendered page as if it were a person clicking through statements.

1. Credential collection: the aggregator stores your username and password (sometimes encrypted, sometimes not) and submits them through an automated browser session.
2. Session automation: a headless browser or bot navigates the bank’s site, clicks through menus, and pulls balance and transaction data straight from the HTML.
3. Parsing: the raw page is scraped for numbers and dates using pattern matching, which breaks the moment the bank changes a class name, moves a button, or redesigns the layout.
4. MFA workarounds: two-factor prompts get relayed to you manually, cached temporarily, or bypassed with security-question answers stored on file, none of which sits comfortably with modern authentication standards.
5. Ongoing maintenance: someone on the vendor’s side has to monitor thousands of bank templates and patch the scraper within hours of a layout change, or data quietly stops flowing.

That last point is the real cost centre. Screen scraping drawbacks rarely show up as a single dramatic failure. Instead, they show up as slow data drift: a balance that is three days stale, a category of transactions that silently stopped importing, a support ticket nobody can diagnose because the scraper “usually works”. Answering how does screen scraping work honestly means admitting it was built for a pre-API era and has been patched to survive ever since, not designed for the compliance environment banks now operate under.

How open banking APIs work: OAuth, tokens and what developers actually get

Open banking APIs authenticate through OAuth 2.0, using either a redirect flow (you’re bounced to your bank’s own login page) or, increasingly, a decoupled flow where you approve the request inside your existing banking app.

• Token issuance and revocation: the bank issues a short-lived access token plus a longer-lived refresh token; either can be revoked instantly from the bank’s own security settings, no vendor involved.
• Structured schemas: responses come back as versioned JSON, typically aligned to the Berlin Group NextGenPSD2 or UK Open Banking standard, so a “transaction” object always has the same shape.
• Testing facilities: most banks expose a sandbox with dummy accounts, letting developers build against realistic error codes (expired consent, rate limit hit, insufficient scope) before going live.
• MFA handled natively: strong customer authentication happens inside the bank’s own app or page, so the integrator never sees, stores, or relays a one-time code.
• Versioning discipline: banks publish deprecation notices and run old and new API versions in parallel, so a schema change doesn’t break production overnight the way a redesigned login page does.

This is where open banking security and developer experience overlap. A token scoped to “read balances and transactions for 90 days” simply cannot be used to move money or reset a password, even if it leaks. Tokenised access also simplifies revocation for support teams, because killing one token doesn’t require rotating a stored password across a dozen dependent services.

Security, consent and regulation: PSD2 and RTS in practice

The regulatory answer to open banking vs screen scraping isn’t really a debate anymore, it’s settled law across the EU and UK. Once the RTS under PSD2 apply, banks must offer at least one dedicated interface for account information and payment initiation providers, and providers must identify themselves rather than impersonating the customer.

Once RTS under PSD2 apply, legacy screen scraping that impersonates users without third-party provider identification is no longer permitted for accessing payment account data; banks must provide an interface or allow identified provider access through the customer interface.

That principle comes directly from the EU Commission’s memo on PSD2 and the RTS, and the technical detail sits in the EBA’s final draft RTS on strong customer authentication and common and secure communication. Three things follow for anyone building or buying screen scraping alternatives:

Fallback isn’t banned outright. Banks with a compliant dedicated interface that passes testing and meets performance parity can be exempted from maintaining a fallback screen-scraping route at all, per the EBA’s own contingency provisions.

Frequency limits apply regardless of method. Access without you actively present is capped at four calls in any 24-hour period unless a higher rate is contractually agreed with the bank, a rule confirmed in the EBA’s working group opinion on API implementation. Building a polling job that hits a bank every five minutes will breach this, API or scraper alike.

Data minimisation and audit trails now matter as much as access itself. Storing more transaction history than a use case needs, or failing to log who accessed what and when, creates liability under GDPR that sits alongside, not instead of, PSD2 obligations. For open banking regulations more broadly, that dual compliance layer is the part most teams underestimate.

Operational trade-offs: reliability, coverage, cost and completeness

Reliability is where the gap becomes hard to argue with. API connections report success rates as high as 99.9% against a scraper’s login flow, which breaks the moment a bank changes a form field. Mean time to repair also differs sharply: an API error usually resolves with a documented fix; a scraper break can sit undiagnosed for days while support tickets pile up.

• Scraping still occasionally wins on coverage for accounts PSD2 doesn’t govern, since the regulation’s scope is limited to payment accounts, leaving some savings, investment or non-payment products outside the mandated interface.
• Cost profiles diverge too: scraping looks cheap upfront but carries an ongoing, unpredictable maintenance bill; API access is usually a flat, quoted per-account fee.
• Historical depth also varies by bank rather than by method, so always check how many months of transactions an interface actually returns before assuming parity.

Pro Tip: Before signing any data vendor contract, ask for their last-90-days API success rate broken down by bank, not as a blended average. A single unreliable bank can drag the average down while the rest of your coverage is fine, and vice versa.

Migration and hybrid patterns: a practical checklist

Moving from scraping to open banking rarely happens in one cutover. It’s a phased process, and rushing it usually means an angry finance team mid-close.

1. Audit your bank coverage against your actual customer base; list which institutions already offer a compliant API and which don’t.
2. Run a pilot on your highest-volume banks first, targeting a 95%+ successful connection rate before expanding, and monitor failure logs daily for the first two weeks.
3. Set a decommissioning date for scraping on covered banks, and tell affected customers at least 30 days ahead so nobody is surprised by a reauthentication prompt.
4. Negotiate SLA terms with your API provider covering uptime, incident response time, and what happens if a bank temporarily drops its interface.
5. Keep a monitored fallback only for the banks that genuinely lack a compliant API, and revisit that list quarterly since coverage keeps expanding.

Zenith’s perspective: lessons from bank sync deployments

Building bank connectivity across 30 European countries teaches you fast that “open banking coverage” is really 30 separate coverage problems, not one. A bank in one market can have a mature, well-documented API while its neighbour three borders over is still running a scraping-era portal with no sandbox at all.

Zenith’s Bank Sync is built as a read-only PSD2 connection precisely because this constraint removes an entire category of risk: there is no credential storage, no session impersonation, nothing for a support team to argue about when a customer asks “what exactly can this thing do to my account?” Nothing. It reads balances and transactions, full stop.

The operational payoff shows up at month-end. Finance teams reconciling bank feeds automatically, rather than re-keying CSV exports, consistently close faster and catch duplicate or missing transactions before they become a spreadsheet argument. That’s the same logic behind why structured cash visibility tends to outperform manual exports even when the raw data is identical.

— Gašper Anderle

How Zenith handles bank sync and migration support

If you’re mid-migration from scraping to open banking, or just tired of stitching CSV exports into spreadsheets by hand, Zenith gives you a direct, PSD2-compliant route rather than a workaround. Setup takes about five minutes per connection, not a sprint.

Zenith’s Bank Sync connects to 2,400+ banks across 30 European countries through a read-only PSD2 connection, with no credentials stored and no scraping involved. Data lands wherever your workflow already lives, Google Sheets, Claude via MCP, a REST API, or plain CSV, at €5 per account per month. If it doesn’t fit your setup, there’s a 30-day money-back guarantee, no drawn-out cancellation process.

For the technical detail on scopes and data delivery, the developer documentation covers exactly what each connection returns. If you’re specifically auditing UK bank coverage as part of a migration checklist, the UK bank sync coverage page lists which institutions are connected today. Start with one high-volume account, watch it run for a week, then decide if it’s worth expanding.

Sources

• EU Commission memo on PSD2/RTS
• Screen scraping vs APIs — Stripe resources