Reviews
Part of Open banking guide: consent, APIs, aggregators, permissions, and data flows
Screen scraping, API access, file export, and bank portal sharing compared
Financial data access methods compared by credentials, scope, freshness, revocation, resilience, provenance, payment authority, and consumer control.
What to take away
- Screen scraping usually depends on a third party navigating account pages, often with shared credentials.
- API access can separate bank authentication from app access and define scopes, but implementation quality still matters.
- File export gives the user a point-in-time copy without a continuing connection.
- Bank portal sharing describes a consumer-facing control point, not necessarily the technical rail behind it.
- Compare credential custody, scope, freshness, revocation, and payment authority instead of choosing by label.
Four services can show the same balance while obtaining it in different ways. The method changes who holds credentials, how often data updates, what breaks the connection, and how a person ends access.
This comparison treats the methods as operating patterns. A provider can combine them or migrate a connection from one to another.
Side-by-side comparison
Screen scraping
- User action
- Gives credentials or completes an automated login
- Continuing access
- Common
- Credentials held by app
- Possible
- Scope control
- May be broad or page-based
- Freshness
- Scheduled or event-driven retrieval
- Revocation
- App, password change, provider block, or several steps
- Common break
- Page change, MFA, credential rotation
API access
- User action
- Authenticates and approves defined access
- Continuing access
- Common or one-time
- Credentials held by app
- Often avoided in redirected flows
- Scope control
- Can be field and account specific
- Freshness
- Scheduled, event-driven, or on demand
- Revocation
- Token or authorization revocation
- Common break
- Token expiry, API change, outage
File export
- User action
- Downloads and uploads a file
- Continuing access
- No, unless user uploads again
- Credentials held by app
- No bank credential needed by recipient
- Scope control
- Limited to file contents
- Freshness
- Snapshot at export time
- Revocation
- Delete copies and stop new uploads
- Common break
- Wrong format, duplicate upload, stale file
Bank portal sharing
- User action
- Selects a service and permissions at the bank
- Continuing access
- Common or one-time
- Credentials held by app
- Often avoided, but verify
- Scope control
- Depends on portal and backend
- Freshness
- Depends on backend connection
- Revocation
- Bank portal control may revoke backend access
- Common break
- Mismatched names, stale portal state
Screen scraping
Screen scraping uses automated software to sign in and collect information rendered for a user. It may parse account pages rather than receive a stable data schema.
Common traits include:
- credentials supplied to an app or aggregator;
- automation that encounters multifactor prompts;
- retrieval affected by page design changes;
- field meanings inferred from screen labels;
- broad visibility once signed in;
- difficult attribution when several services share one login path.
FINRA's explanation of financial data aggregation methods distinguishes API connections from screen scraping, which uses credentials to sign in and collect account information. It also advises consumers to check the connection method, scope, privacy terms, retention, and how to end access.
Scraping is not automatically inaccurate, and an API is not automatically safe. The stronger conclusion is narrower: credential sharing and page interpretation create risks that a defined, provider-operated data interface can avoid.
API access
An API exposes defined requests and responses. A redirected authorization flow can let the consumer authenticate with the financial institution and let the app receive a token rather than a password.
A useful API contract specifies:
- account and data scopes;
- read versus payment permissions;
- token lifetime and refresh rules;
- response fields and units;
- pending and posted states;
- timestamps and time zones;
- pagination and duplicate handling;
- error codes and retry behavior;
- revocation and audit events;
- version changes and retirement dates.
API access can still be excessive. A token may cover too many accounts, remain valid too long, or reach an insecure downstream store. Compare the actual controls, not the presence of the letters API.
File export and upload
A customer downloads a CSV, QFX, OFX, PDF, or another supported file and supplies it to a second service. This creates a point-in-time handoff.
Advantages:
- no ongoing bank login is required by the recipient;
- the user can inspect the file before upload;
- the time period can be selected;
- revocation is simple because no live connection exists.
Limits:
- the copy becomes stale;
- the file may include more rows or identifiers than needed;
- schema and date formats can be misread;
- repeat uploads can create duplicates;
- deleting the source file does not remove the uploaded copy;
- payment initiation is not part of a normal transaction-file export.
Encrypt sensitive files at rest, transfer them through an approved channel, and delete working copies under a documented retention rule.
Bank portal sharing
A bank portal may show connected apps and ask the consumer to choose accounts or permissions. This is a user-control surface. Behind it, the connection may use an API, an aggregator arrangement, or another bank-managed mechanism.
Portal benefits can include:
- institution-controlled authentication;
- visible app or aggregator names;
- account-level selection;
- stated scopes and duration;
- a central revocation control;
- access or authorization history.
Do not infer more than the portal proves. A clean permission screen does not disclose every downstream processor, cache, transformation, or retention exception.
What the older scraping-to-API transition shows
A federal consumer-law taskforce report describes screen scraping as access using credentials and explains that API arrangements can allow consumers to authenticate directly with a financial institution and give an aggregator an access token. The CFPB taskforce report's data-access discussion supports that technical distinction, but it does not make every API connection equivalent or prescribe one consumer choice.
The operational lesson is to document the authentication party, credential custodian, token issuer, permitted fields, and revocation point.
Choose by job, not fashion
For a one-time analysis
A narrowly scoped export or one-time API pull may avoid continuing access. Confirm what the recipient retains.
For a live budgeting dashboard
An API connection with defined account scope, clear refresh timestamps, and visible revocation may fit better. Review whether an aggregator is involved.
For a record you must preserve
An exported file can create stable evidence, provided its source, date range, format, and integrity are recorded.
For payment initiation
Treat payment authority separately from data reading. Require a transaction-specific review, amount, destination, timing, and confirmation.
Decision questions
Before connecting, answer:
Before Connecting: Key Questions
- Who receives my login credentials?
- Which accounts and fields are accessed?
- Is access one-time or continuing?
- Can the service initiate a payment?
- How fresh is the displayed data?
- Where can I revoke access?
- What data remains after revocation?
Common questions
Is API access always safer than screen scraping?
No. It can reduce credential sharing and define scope, but token, endpoint, application, and storage security still matter.
Does a file upload create an open connection?
Normally no. It creates a copy that the receiving service may retain and process.
Is a bank portal itself an API?
No. It is a user interface that may control an API or another backend method.
Can any method include payment authority?
Some connected services can initiate payments. Verify that permission independently from read access.
