The short answer
If you use a budgeting app, accounting tool, or net-worth tracker connected to your European bank account, you have noticed that every 90 to 180 days the app prompts you to re-authenticate with your bank.
This recurring friction is a mandatory security control enforced by PSD2 Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA). The consent expiry rule prevents forgotten apps from permanently reading your bank account data in the background without your active knowledge.
The Regulatory Evolution: 90 Days to 180 Days
Under the original PSD2 regulations introduced across the EU and UK in 2019:
- The 90-Day Rule: Account Information Service Providers (AISPs) were legally required to obtain fresh Strong Customer Authentication (SCA)—meaning logging into your bank with 2FA—every 90 days.
- The Friction Problem: Users found 90-day re-authentication frustrating, leading many to abandon budgeting apps or fall back to insecure screen-scraping workarounds.
- The PSD2 Amendment (180-Day Rule): Financial regulators (such as the EBA and the UK FCA) updated rules to extend the maximum consent re-authentication window from 90 days to 180 days, provided the initial connection underwent full SCA.
How Consent Expiry Works Behind the Scenes
Day 1: Initial Connection
┌─────────────────────────────────────────────────────────────┐
│ User authenticates with Bank via SCA (Biometrics / 2FA) │
│ Bank issues OAuth Access Token + Refresh Token to AISP │
└──────────────────────────────┬──────────────────────────────┘
│
Day 1–179: Active Data Refresh │ (Background Sync)
┌──────────────────────────────▼──────────────────────────────┐
│ AISP uses Refresh Token to pull daily balance/transactions │
└──────────────────────────────┬──────────────────────────────┘
│
Day 180: Token Expiry │
┌──────────────────────────────▼──────────────────────────────┐
│ Bank invalidates Refresh Token │
│ AISP prompts User: "Please re-connect your bank" │
└─────────────────────────────────────────────────────────────┘When you connect an app to your bank:
- OAuth Authorization: Your bank issues an encrypted access token and refresh token to the licensed AISP.
- Background Refresh Limit: The AISP can use the refresh token to pull transaction data in the background up to 4 times per day without your active involvement.
- Mandatory Expiry: Once the 180-day window lapses, your bank’s API rejects refresh requests until you complete a new SCA login flow directly with your bank.
Why Consent Expiry Exists as a Security Safeguard
While consent prompts can be inconvenient, the expiry mechanism provides critical privacy protections:
- Eliminates Zombie Connections: If you uninstall an app or stop using a service, the consent expiry rule ensures the vendor automatically loses access to your bank within 180 days, preventing indefinite background data harvesting.
- Limits Data Exposure During Vendor Breaches: If an AISP suffers a database breach, an expired token prevents attackers from making live API calls to your bank.
- Forces Transparency: Re-authentication reminds consumers which third-party applications currently possess active pipelines into their financial accounts.
What expiry does not do
The protection is real and it is narrower than most people assume. Three limits are worth stating plainly.
It does not delete anything. When a consent lapses, the app stops receiving new transactions. Everything it already pulled — commonly up to 24 months of history from the initial sync — remains in its systems under its own retention policy. Expiry is an access control, not an erasure mechanism, and the two are governed by different law. What happens to your data after you revoke consent covers how to actually get it deleted.
It does not cover screen scraping. If an app holds your banking username and password rather than a token, nothing expires. Credentials do not have a lifetime, your bank cannot distinguish that app’s logins from your own, and there is no consent record to lapse. This is one of the clearest practical arguments for preferring licensed API access — see screen scraping vs Open Banking API.
It does not apply to payment mandates. A direct debit authorisation or a recurring card payment is a separate instrument with its own lifecycle. Neither expires because an account information consent did.
Re-authentication is a phishing opportunity
This is the part worth internalising, because the mechanism trains a habit that attackers want.
Every 90 or 180 days, you are conditioned to expect an unprompted message saying your bank connection has expired and asking you to re-authenticate. That is exactly the shape of a phishing email, and unlike most pretexts, this one is true often enough that people stop questioning it.
The defence is procedural. Never re-authenticate from a link. Open the app yourself, from your own device, and start the reconnection from inside it. If the prompt is genuine, the flow is there waiting. If it is not, you have lost nothing.
When the flow does start, check three things:
- The authentication page is on your bank’s own domain, in a real browser window where you can see and inspect the address bar. An app that renders the bank login inside its own embedded view is doing something you cannot verify.
- The entity named on the consent screen is the app or its aggregator, and it is the one you expect.
- The scopes and duration match what you had before. A reconnection that suddenly requests additional accounts or payment initiation permission is a change, not a renewal.
Why apps break before the deadline
Consent expiry is the designed reason a connection stops. It is not the most common one, and knowing the alternatives saves a lot of pointless re-authentication.
Connections also fail when you change your online banking password or credentials, when your bank rotates or deprecates an API version, when the bank’s interface has an outage — availability varies considerably between institutions — when the account itself changes, as in a product migration or a new card, or when you revoked the consent at the bank and forgot.
The practical distinction: if one app breaks, the problem is usually that app or its consent. If every connected app breaks on the same day, the problem is at your bank, and re-authenticating repeatedly will not fix it. Wait, then reconnect once.
A routine that makes this work for you
The expiry prompt is the only moment the system reliably puts a decision in front of you. Treating it as friction to be cleared is the failure mode; treating it as a scheduled review is the whole value of the control.
When a prompt arrives, ask two questions. Have I deliberately used this app since the last renewal? Does it still need every account I gave it? Renewing is a positive act — if the honest answer to the first question is no, let it lapse.
Then finish the job properly, because lapsing is not enough on its own:
- Revoke Expired Tokens at Your Bank: Log into your bank’s web portal and check the “Connected Apps” or “Third-Party Permissions” section to clear out stale connections. A lapsed consent can linger in the list, and clearing it is what makes the register readable next time. Read our guide on what you agree to when an app connects to your bank.
- Request deletion for apps you are abandoning: Lapsing stops the reads; only an erasure request removes the history.
- Narrow the scope on renewal: If the consent screen lets you select accounts, drop any the app does not need. Most people grant everything on first connection and never revisit it.
- Verify Aggregator Identity: When re-authenticating, ensure the bank authentication page redirects to your bank’s official domain (
https://yourbank.com/...), not an unverified third-party iframe. Read our guide on how to check an app is a licensed AISP.
Twice a year, per app, this takes a couple of minutes and is the closest thing Open Banking has to a built-in privacy review. How to audit which apps can reach your money covers the wider sweep for everything that does not send you a prompt at all.