Consent authorisation abandonment is the hidden metric in open banking. Teams optimise the onboarding funnel carefully up to the point where the user enters their email, then hand the flow over to the bank's authorisation screen and hope for the best. This article covers the consent lifecycle decisions — at the API level and the product level — that determine whether users complete the bank connection, stay connected for 90 days, and reconnect gracefully when re-authentication is required.
What consent actually is in PSD2
Consent in PSD2 is not just a user tapping "I agree". It is a formal data structure — a consent resource — that the ASPSP creates and maintains, which specifies:
- Which account data permissions are granted (ReadAccountsDetail, ReadTransactionsDetail, ReadBalances, and so on in OBIE terms)
- Which accounts or IBANs are in scope
- The expiry date of the consent
- The date range for historical transaction access
- The PSU's identity as verified by the ASPSP's SCA mechanism
The consent resource has a lifecycle: it starts as AwaitingAuthorisation, moves to Authorised once the PSU completes SCA, and can later reach Expired (at the 90-day boundary or the requested expiry date, whichever comes first), Rejected (if the PSU declines at the bank), or Revoked (if the PSU revokes access through the bank's interface).
Your application needs to track this lifecycle, not assume that a consent which was authorised last week is still usable today.
Requesting the minimum necessary permissions
The EBA RTS implementing PSD2 requires that TPPs request only the data they actually need for their service — this is the data minimisation principle. But there is also a product reason to request minimal scope: the more permissions you request, the more explanation the bank's authorisation screen shows to the user, and the higher the abandonment rate.
A personal finance app that needs to categorise spending should request ReadTransactionsDetail and ReadBalances. It does not need ReadAccountsDetail with full account metadata, ReadDirectDebits, and ReadStandingOrders on day one. Incremental permission requests — ask for what you need at onboarding, request additional permissions later when a specific feature requires them — produce better completion rates and create a more honest data relationship with users.
From the API side, requesting minimal permissions also reduces the probability of partial authorisation — where the PSU grants some permissions but not others at the bank's screen. Some banks allow users to deselect individual data categories; if your code assumes all requested permissions were granted and calls an endpoint the user declined, you receive a 403 rather than gracefully degrading.
Designing the redirect experience
Your application controls what happens before and after the bank redirect. What happens during the redirect is the bank's UI. The transition between the two is where most abandonment occurs.
Before the redirect
Tell the user exactly what is about to happen before you initiate the redirect. Most abandonment at the bank screen happens because users land there unexpectedly, feel uncertain about what they are authorising, and close the tab rather than proceed. A short explanation screen — "You'll be taken to [bank name]'s secure login. You'll need your mobile banking app to approve access." — materially reduces abandonment.
If you are using app-to-app flows (the user's browser deep-links into the bank's mobile app), make this explicit. Users on iOS who are not expecting to switch apps will sometimes tap the back button when their banking app opens, aborting the flow.
After the redirect
Your redirect_uri callback must handle three outcomes: successful authorisation (with a code), user rejection (the ASPSP redirects back with an error parameter), and timeout (the user never returns). The timeout case is invisible at the HTTP level — you simply never receive the redirect. Implement a session expiry mechanism that clears pending authorisation state and prompts the user to try again if they return to your app without completing the bank flow.
Never use a redirect_uri that navigates the user deep into your app immediately on callback. Land them on a neutral confirmation step that verifies the authorisation succeeded before proceeding. This gives you a recovery point if the code exchange fails.
The 90-day consent renewal problem
The 90-day SCA re-authentication requirement is where many fintech products leak users. A user who connected their bank account in month one of your product reaches the 90-day boundary at a moment of low intent — they are not in the process of actively using your product, and a notification saying "reconnect your bank" feels like friction with no immediate benefit.
Strategies that improve 90-day renewal rates:
Notify in context, not cold
A renewal notification sent seven days before expiry, while the user is actively using your product (or triggered by a product event like an incoming transaction), converts better than a cold push notification sent the day before expiry. Users who are already looking at their transaction history are already in the right frame of mind to go through a bank redirect.
Make the renewal intent clear
The bank's re-authorisation screen looks identical to the initial authorisation screen. Users who do not remember connecting their bank account initially will treat re-authorisation as a suspicious prompt — "did I sign up for something I don't remember?" Pre-frame the renewal: "Your connection to [bank] is expiring. This is a routine re-authorisation required by open banking regulation — your data has been safe throughout."
Handle expired consent gracefully in the product
When a user navigates to a feature that requires bank data, and the consent is expired, do not show an error. Show an inline banner that explains the connection needs renewal and offers a direct CTA to reconnect. An error state teaches users that the product is broken; an inline renewal prompt teaches users that the product is managing their connection proactively.
Consent revocation and the revocation endpoint
PSD2 requires ASPSPs to provide revocation mechanisms. Under UK OBIE, an ASPSP must provide a way for the PSU to revoke a TPP's access through their own banking interface — and when revocation occurs, the ASPSP must notify the TPP within a commercially reasonable time. Under Berlin Group, the DELETE method on the consent resource endpoint achieves revocation programmatically.
Your application must handle revocation events. When a consent is revoked:
- Stop making API calls against that consent — they will return 401 or a consent-revoked error
- Delete or invalidate the stored access token and refresh token associated with that consent
- If you receive a revocation webhook or notification, process it promptly — do not let revoked consent state persist in your system
- Decide whether to prompt the user to reconnect or silently degrade — this is a product decision that depends on how central the bank connection is to your product's core value
ASPSP webhook delivery for revocation events is inconsistent across implementations. Some banks notify promptly; others do not implement the notification at all. Periodic polling of consent status for active connections is a defensive pattern worth implementing regardless of whether you expect webhook delivery.
TPP-side consent revocation
Your application should also allow users to disconnect their bank account — this is both a GDPR right (the right to withdraw consent for data processing) and good product design. Provide a settings screen where users can see which bank connections are active and disconnect any of them. When a user disconnects:
- Call the ASPSP's consent deletion endpoint (DELETE
/account-access-consents/{consentId}in OBIE, DELETE/v1/consents/{consentId}in Berlin Group) - Delete the stored tokens on your side
- Delete or anonymise the bank data you have fetched, per your data retention policy and GDPR obligations
Variable recurring payments: the emerging consent evolution
In the UK, Variable Recurring Payments (VRPs) via open banking represent a consent model evolution beyond the 90-day AIS pattern. VRP consents allow TPPs to initiate payments on behalf of a user within pre-agreed parameters (amount limits, frequency limits, payee constraints) without requiring SCA on each individual payment. VRPs for sweeping (moving money between a user's own accounts) became available under UK OBIE in 2022. Extension of VRPs to third-party payment use cases is on the JROC roadmap.
VRP consent objects have a different lifecycle from AIS consents — they are persistent until revoked rather than subject to 90-day re-authentication. Designing your consent management layer to accommodate VRP consent types now, rather than retrofitting later, avoids architectural debt.
Checklist for production-ready consent management
- Store consent ID, status, expiry date, and granted permissions durably per user-bank connection
- Poll or webhook-track consent status for changes (revocation, expiry)
- Implement 90-day renewal notifications at 14, 7, and 1 day before expiry
- Handle partial authorisation (not all requested permissions granted)
- Provide a user-facing consent management UI (view connections, disconnect)
- Call the DELETE endpoint on user-initiated disconnection and on revocation events
- Never cache bank data fetched against an expired or revoked consent as if it were fresh
- Test the full lifecycle — authorisation, 90-day expiry, revocation — against each bank's sandbox before going live
