Open Banking Consent UX: Designing the Screen Where Users Decide to Trust
In open banking, the consent screen is the product's trust moment. A person is deciding whether to let a service read their financial data, and the interface has a few seconds to make that decision feel safe. I led the redesign of the bank-linking and consent journey for Tarabut, a white-label open banking platform used across partner banks in the GCC. This is what the work taught me about open banking consent UX.
Why the consent screen decides the whole journey
The baseline funnel recorded 530 sessions at launch, 282 at provider selection and 136 at consent. The data showed where people stopped; it did not say why. So alongside the sessions and support feedback in the original study, I reviewed what each screen asked a person to understand. The core problem was confidence, not usability: recognising the bank, understanding the request and feeling in control before continuing.
Regulation raises the stakes. Saudi Arabia's central bank began licensing fintech firms for open banking in March 2026, and reporting on the process lists customer consent mechanisms among what applicants must demonstrate. For designers in the region, consent UX is now part of compliance as well as conversion.
What the old flow got wrong
The earlier journey had four screens. The permission screen explicitly named payments, bank usernames and passwords in a section explaining what access did not allow. The intent was reassurance, but it put the most alarming possibilities directly in the reading path.
The user also had to connect several separate ideas: a service asking for access, a 12-month period, a generic Confirm button, a redirect, and an account-selection screen. Each step left a different question unanswered.
Four questions every consent screen must answer
I organised the redesign around the questions a person silently asks before agreeing:
- Scope: what can this service actually access? Show the permitted data in clear, inspectable categories.
- Purpose: who is asking, and why do they need it? Name the requester and connect the data to the service.
- Control: how long does sharing last, and can I stop it? Keep the dates and the revocation message next to the decision.
- Continuity: where will this button take me? Name the next destination and explain the handoff to the bank.
Recognition comes before permission
The bank list already had logos, but as small entries in a dense sequence. I gave each bank its own card with a larger target and a consistent logo and name relationship. The same card system accommodated the bank sets for Saudi Arabia and Bahrain without changing the interaction.
In a comparison with 26 Arabic-speaking participants, 77% preferred the bank grid. In a separate comparison with 30 Arabic-speaking participants, 63% preferred permissions grouped into categories. These are preference results from small samples, not conversion measurements.
Designing consent in Arabic and English
The journey ships in Arabic and English on mobile and desktop, so every state had to hold up in right-to-left reading as well. Consent copy is where translation shortcuts hurt most, because a vague word about data access erodes the trust the screen exists to build. If you design bilingual interfaces, my practical review guide on Arabic and RTL UX covers the layout and text issues in detail.
What changed, and how far to trust the number
Consent-journey completion rose 27%, as reported in the original study. The study does not state the baseline or whether the 27% is relative or in percentage points, so treat it as a self-reported directional result. The more transferable lesson is the method: find the question the screen leaves unanswered, and answer it at the moment it matters.
Building an open banking product in the Gulf?
I work as a Lead Product Designer on open banking and fintech journeys, remotely on Gulf time. If you are designing a consent flow, bank-linking journey or payment initiation experience, I am happy to review it with you.