The short answer
Two apps can show you the same balance and reach it in completely different ways. One holds a scoped, revocable token issued by your bank. The other holds your banking password and logs in pretending to be you.
The app rarely tells you which it is doing, and both look identical once connected. But the difference is visible during setup if you know what to watch for, and it stays visible afterwards in your bank’s own interface. Here is how to establish which one you are dealing with.
Why it matters is covered separately in what you actually agree to when an app connects to your bank. This page is only about telling them apart.
The single most reliable test: where do you type your password?
If you type your online banking credentials into the app’s own screen, the app has your credentials. That is credential sharing, and everything downstream follows from it.
If you are sent to your bank’s own website or app to authenticate, and you come back afterwards, the app was issued a token and never saw your secret.
This one check settles most cases in about five seconds. The remaining checks exist because the boundary can be deliberately blurred.
Where the blur happens
A convincing in-app screen can be styled to look like your bank’s. What you are verifying is not the visual design but the origin of the page.
On the web, look at the address bar during authentication. It must be your
bank’s real domain, over HTTPS, and you should read the whole domain rather than
just noticing that the bank’s name appears somewhere in it. yourbank.com and
yourbank.secure-login.example are not the same thing.
On mobile, a proper implementation either opens your bank’s actual app or opens a system browser view that displays the URL. An embedded webview with no visible address bar is a design that cannot be verified by the user, which is a finding in itself even when the app behind it is honest.
Five further checks
1. Is there a consent screen listing scopes and a duration? A PSD2 interface produces one, generated by your bank, naming what will be shared and for how long. A scraper has nothing to generate it from, so either there is no such screen or it is written by the app and lists no expiry.
2. Does the app appear in your bank’s connected-apps list? This is the strongest confirmation available, and it is retrospective, so it works after the fact. Open your bank’s own interface and find the section listing third-party access. A licensed provider using the API appears there as a revocable connection. A scraper cannot appear there, because from the bank’s perspective there is no third party — there is only you, logging in.
3. Does it ask for a one-time code every refresh? Scrapers have to complete your bank’s full login each time they poll, so they hit strong customer authentication repeatedly and need you to forward codes. Being asked for a verification code every time the app syncs is close to conclusive.
4. What does the privacy policy say it stores? Search the terms for “credentials”, “username and password”, “on your behalf”, and “you authorise us to access”. Language granting the provider permission to log in using your credentials describes scraping, whatever the marketing page says. Note the date you read it and the tier it applies to, because these documents change quietly.
5. Is the provider on a regulator’s register? In the EU, an app doing account information properly is authorised as an AISP, and the authorisation is listed on a public register held by a national competent authority. Check the register rather than the badge on the company’s website. Absence from the register while claiming Open Banking access is the clearest possible answer.
Weaker signals, and why they mislead
Some heuristics circulate that are less reliable than they look.
Breadth of coverage. Scrapers can support institutions that never built an API, so unusually wide coverage of small banks used to imply scraping. It no longer settles anything: large aggregators now mix both methods, using the API where one exists and scraping where it does not, sometimes within the same app.
Sync speed and freshness. Slow or scheduled refreshes were once a scraping tell. API rate limits produce the same pattern, so this distinguishes nothing.
Fragility. An app that breaks whenever your bank redesigns its login page is almost certainly scraping, since an API contract would not care about layout. But this only tells you after a breakage, which makes it an observation rather than a check.
Because aggregators mix methods, the honest form of the question is not “does this app scrape?” but “how does it connect to my bank?” The answer can differ between two institutions inside the same app, and coverage pages sometimes say so if you read the footnotes.
What to do with the answer
If it uses the API, your remaining questions are about privacy rather than security: retention periods, sub-processors, and what happens to the data you already shared if you disconnect.
If it uses your credentials, three consequences follow, and they are worth being clear-eyed about. The app can do anything you can do, not merely what you agreed to share. Your bank’s terms may treat credential sharing as a breach that moves fraud liability onto you — worth reading before deciding this is acceptable. And revoking access means changing your banking password, because there is no connection for the bank to switch off.
If you decide to disconnect either kind, do it at the bank rather than only in the app, and remember that revoking future access does not erase what was already collected. That is a separate request to the provider.
The check worth doing today
Open your bank’s connected-apps list. Not the app’s settings — the bank’s. Every connection there is one you granted at some point, and the list is usually longer than people expect. Anything you no longer use should not still be reading your transaction history every night.