PSD2 Open Banking Consent Screen UI in React Native

What is a PSD2 consent screen, and why is it a regulated surface?

The screen where a user explicitly authorizes your app to access their bank data or initiate a payment on their behalf, under European open-banking law. The EU’s Payment Services Directive 2 (PSD2) forced banks to open APIs (open banking) so licensed third parties can, with the user’s consent, read account information or make payments, and the consent screen is where that permission is granted. It looks like a checkbox flow and is actually a legally-defined authorization with specific requirements, so building it carelessly is not just bad UX, it is non-compliant.

The honest framing first: this consent flow runs on top of a licensed provider, an account-information or payment-initiation service provider (AISP/PISP) that holds the regulatory permission, and your app surfaces the consent and hands off to the bank’s own Strong Customer Authentication. You do not touch bank credentials; the user authenticates at their bank, and your app receives scoped, time-limited access. A screen that collects bank logins directly is the anti-pattern PSD2 exists to kill.

What must the consent screen actually show?

Explicit, specific, informed permission, because vague consent is not valid consent under the regulation:

Element	What it states	Why it is required
Which bank	The institution being connected	The user picks and confirms
What data / action	Accounts, balances, transactions, or a payment	Consent is per-scope, not blanket
Duration	How long access lasts (capped, re-consent needed)	Access is time-limited by law
The provider	The licensed AISP/PISP involved	Transparency about who has access
Revocation	How to withdraw consent	The user can revoke anytime

The granularity is the legal point: consent must be specific (read these accounts for this purpose), not a blanket “connect my bank,” and informed (the user understands what they are granting), so the screen spells out exactly what is accessed and for how long before the user proceeds. Access is also time-limited, historically requiring re-authentication roughly every 90 days for ongoing access, so the flow must handle re-consent honestly rather than implying permanent access. This is the same data-minimization-and-clarity discipline as the GDPR consent banner, with money-grade stakes.

How does the flow run without touching credentials?

Through a redirect to the bank and back, the SCA handoff that keeps your app out of the credential business. The sequence: the user selects their bank and reviews the consent, your app (via the AISP/PISP) redirects them to their bank’s own authentication (in a system browser or the bank’s app), the user authenticates there with Strong Customer Authentication (two independent factors, though low-value payments under about €30 can be exempt), and control returns to your app with scoped access, never the password. The credential never enters your app, which is both the law and the security model, the same system-browser, never-an-embedded-webview rule as the FranceConnect identity flow.

The UI honesty around it: a clear handoff moment (“you’ll authenticate at your bank”), an honest return state, a granted-access summary showing exactly what the user authorized and when it expires, and a real revocation path. SCA can fail or be abandoned (the user backs out at the bank), so the consent flow treats a dropped authentication as a calm “not completed,” never an error tone, and never a dead end.

What completes a compliant consent flow?

The trust surface and the honest scope. A connections screen where the user sees every active consent, what it grants, and when it expires, with one-tap revocation, because PSD2 gives users the right to withdraw and the app must make it real. Clear provider attribution (who the licensed AISP/PISP is). And accurate language about what the app does: an account-information app reads, a payment-initiation app moves money once per explicit authorization, and conflating them, or implying broader access than the consent grants, is the misrepresentation the regulation forbids.

The screens, the bank selector, the consent detail, the SCA handoff, the active-connections list with revocation, come as a free VP0 design, so an agent builds the AISP/PISP integration onto a UI already shaped for specific, time-limited, revocable consent. The broader render-the-UI, route-through-the-licensed-entity pattern is the same one behind every regulated build like the Klarna checkout widget.

Key takeaways: a PSD2 open-banking consent screen

• It is a legally-defined authorization, not a checkbox: specific, informed, time-limited consent under EU open-banking law.
• Run it on a licensed AISP/PISP: the provider holds the permission; your app surfaces consent and hands off, never touching credentials.
• Consent is per-scope and time-limited: state exactly what is accessed and for how long, and handle the ~90-day re-consent honestly.
• SCA is a redirect to the bank and back: the user authenticates at their bank in the system browser; the password never enters your app.
• Revocation is a right, made real: an active-connections screen with one-tap withdrawal, and accurate language about read versus pay.

Frequently asked questions

How do I build a PSD2 open-banking consent screen in React Native? Build a flow on top of a licensed AISP/PISP: a bank selector, a consent detail stating exactly what data or action is authorized and for how long, a redirect to the bank for Strong Customer Authentication, and an active-connections screen with one-tap revocation. Never collect bank credentials in your app. A free VP0 design supplies the consent and connections screens.

Does my app handle the user’s bank password? No, and it must not: under PSD2 the user authenticates at their own bank via Strong Customer Authentication, typically through a redirect to the bank’s app or website, and your app receives scoped, time-limited access, never the credentials. A screen that collects bank logins directly is exactly the anti-pattern PSD2 was created to eliminate.”}, {“q”:“What makes open-banking consent legally valid?”,“a”:“It must be specific (read these accounts for this purpose, not a blanket connect-my-bank), informed (the user understands what they grant), and time-limited (access expires and needs re-consent). The screen must state the scope, duration, the licensed provider involved, and how to revoke, because vague or blanket consent is not valid consent under the regulation.”}, {“q”:“How long does PSD2 access last?”,“a”:“It is time-limited by law: ongoing account access has historically required re-authentication roughly every 90 days, so the flow must handle re-consent honestly rather than implying permanent access. The granted-access summary should show when the consent expires, and the app re-prompts when it lapses.”}, {“q”:“What is the difference between an AISP and a PISP?”,“a”:“An Account Information Service Provider (AISP) reads bank data (balances, transactions) with consent; a Payment Initiation Service Provider (PISP) initiates a payment on the user’s behalf per explicit authorization. They are different licensed roles, and the app’s language must accurately reflect which it does rather than conflating read access with the ability to move money.”}, {“q”:“How does revocation work in a PSD2 app?”,“a”:“PSD2 gives users the right to withdraw consent, so the app must provide a real, easy revocation path, typically an active-connections screen listing every consent, what it grants, and when it expires, with one-tap withdrawal. Making revocation genuine, not buried, is both a legal requirement and a trust feature.A free VP0 design supplies the consent and connections screens.