How should a bank app design open finance consent on a legacy core?
A bank app’s open finance consent journey has more states than approve and revoke, and an older core decides how many of them the bank can show.
Illustrative situation: a customer of an invented Gulf bank taps “Connect my bank” in a budgeting app. The bank’s app opens, asks for a face scan and lists two accounts. The customer ticks both and approves. Back in the budgeting app, one account appears and the other is missing, with no message. Three weeks later the customer opens the bank app to stop the sharing and cannot find where. The scene is invented. Each gap has a plausible cause, because consent, accounts and payments sit on different systems, and nobody designed the journey as a whole.
Humbleteam, a digital product design agency, publishes this guide. It covers the screens and states of an open finance consent journey for a bank whose accounts or consent records sit on an older core: arrival from a third party, account selection, duration, data consent versus payment consent, the bank’s own consent dashboard, revocation and errors. Rules and guidelines are described as of November 3, 2026 and can change. This is general information, not legal advice. Your compliance team decides what applies and approves the wording.
What do the rules say the consent journey must do?
In the UAE, the Central Bank’s Open Finance Regulation says data sharing and transaction initiation are always subject to the user’s express consent, appropriate authentication and secure communication. The rulebook lists it as in force, last issued on July 10, 2025. Several clauses shape screens directly:
- Consent must be specific to a purpose, informed, unambiguous and freely given. When several purposes are involved, each needs its own clearly separate consent (Article 22).
- The customer can withdraw consent at any time. The provider must explain that right, and how to use it, when it asks for consent. Withdrawing must be at least as simple as giving consent.
- For a recurring transaction, the consent states its validity period, up to 12 months.
- Payment consent covers each transaction. For a recurring payment it covers the parameters set at the start: the account, the nature of the payment, the value, the beneficiary and the value date.
- The bank must apply at least two-factor authentication when a customer reaches account information, or starts a payment, through a provider (Article 18).
- After a payment is initiated, the bank must display its status to the customer until it completes (Article 17).
The Regulation does not use the word “dashboard”. It does list a Consent and Authorization Manager among the shared services, either an app for users or a set of APIs, for creating, managing, enforcing and revoking consents. It also lets the central API hub set rules for the customer journey, including app-to-app consent.
Customers meet this under a public name. FAB, a UAE bank, tells its customers that open finance is known as AlTareq, and that Nebras operates the central platform. Consent starts in the provider’s app and is confirmed in the bank’s app or in the AlTareq Consent Mobile App. Customers can view, pause or cancel consent in the bank’s platform, the provider’s platform or the central app. Consent expires after at most one year unless extended.
For screen-level detail, the most complete public source is from the UK. Open Banking Limited’s Customer Experience Guidelines, version 4.0.1, were published March 18, 2026. They split the work differently from FAB’s description: the provider collects consent, and the bank authenticates the customer and selects accounts. Check which split your bank follows before copying a screen.
What should the customer see when a third party sends them to the bank app?
We suggest four moments.
On arrival, name the provider before the customer logs in. The UK guidelines require the bank to show the provider’s trading name, and the agent’s name if one acts for it, on authentication screens and dashboards. The same guidelines ask for parity of experience: authenticating through a provider should take no more steps than the customer’s normal login. They also say customers must be able to use their usual method, such as the bank’s mobile app. The guidelines also state that desktop browser journeys have lower consent success rates than app-to-app redirection, without giving a figure.
For account selection, list the accounts that can be shared. Where the core cannot serve an account, say so on its row. A missing account with no explanation is the first gap in the opening scene.
On the review screen, show the purpose, the accounts, the data types, the period of data requested, the end date of the consent and where to stop it. The UK guidelines say the consent request should give the purpose, who else sees the data and when consent expires, and that the bank must not ask the customer to confirm a consent already given to the provider. If your regime puts confirmation in the bank’s app, as FAB describes, this screen is yours, and it carries the consent.
On return, show an outbound screen with the result and a note that the customer is going back to the provider. The UK guidelines recommend this and call clear on-screen messaging essential for adoption.
How is payment consent different from data consent?
Data consent describes a stream: which accounts, which data, for how long. Payment consent describes an instruction: the account, the amount, the beneficiary and the date, as Article 22 lists them. The review screen for a payment should therefore read like the confirmation screen of the bank’s own transfer, with the provider’s name added.
The legacy question is what the bank can say next. Article 17 asks for the payment’s status to be shown until completion. If the core posts in batches, “Accepted” and “Booked” are different states, and the customer should see both words. Wording for pending states is covered in the guides linked at the end.
What belongs in the bank’s own consent dashboard?
The UK guidelines call the bank-side screen an access dashboard and list a minimum. Each row shows the provider’s trading name, account type, consent expiry date, one status flag (“Active” or “Connected”) and a revoke button. The bank should also show when data was last shared. A detail page adds the account identifier, the data categories, the date access began and the expiry. History keeps revoked and expired connections visible. The guidelines advise placing the dashboard no more than two clicks from the home screen and naming it in customer words such as “open banking connections”, not “consent” or “permissions”.
First, the bank cannot always know the full state. In the UK, since the FCA’s policy statement PS21/19, the provider reconfirms consent every 90 days, and the bank no longer needs to re-authenticate the customer on that cycle. So the bank cannot see whether the customer reconfirmed. The guidelines tell banks to use one status flag and to advise customers to check the provider. They also recommend showing when data was last shared, which gives the customer the clearest picture. That field needs a log of every data call against a consent. If the core cannot keep one, we suggest logging at the API layer.
Second, dashboards drift apart. The notifications guidance calls the most common issue a customer revoking at the bank while the provider’s dashboard still shows the consent as live. It describes push and pull notifications as fixes. Revocation should take effect when the customer taps, not at the next batch. In our view that means the consent record lives in a system that updates in real time, even when the accounts do not.
What should the states and errors look like?
The UK read/write API gives one public set of consent statuses: awaiting authorization, rejected, authorized, canceled (by the customer on the bank’s dashboard, or by the bank) and expired. Take UAE statuses from the UAE standards your bank must follow. The table below is a worksheet built on the UK set, extended with states we think a legacy core adds.
| State | Bank app shows | Dashboard shows | Core must record | Legacy limit and workaround |
|---|---|---|---|---|
| Awaiting authorization | Provider name, accounts, purpose, end date, “Approve” | Nothing yet | Consent ID, provider, requested data, timestamp | Slow account list. Cache the list with an “as of” time |
| Authorized | Return screen with result | Active, end date, last data shared | Accounts chosen, data types, end date, who approved | Core logs no data calls. Log at the API layer |
| Authorized, one account limited | Row note: “Balance as of last close” | Same note on the detail page | Which account, which limit | Core returns batch balances. Label the age, do not hide |
| Rejected or timed out | What happened, what was shared (nothing), try again | Not listed, or in history as failed | Reason code, timestamp | Core call exceeds the timeout. Offer the accounts that did answer |
| Expiring soon | Reminder with an extend button | Active, ends in N days | Reminder sent, extension request | Reminder jobs need a scheduler outside the core |
| Expired | Short notice, how to reconnect | History, expired | Expiry timestamp | Expiry must stop data calls without a batch |
| Revoked by the customer | “Sharing stopped”, what happens to data held | History, revoked, date | Revocation timestamp, channel | Must not wait for end of day. Tell the provider at once |
| Revoked at the provider | Notice if the bank is told | History, revoked at provider | Notice time | Bank learns only if told. Show “last data shared” |
| Payment accepted, not booked | Payment status, “Accepted” | If recurring, the mandate, next date | Instruction, status history | Posting happens in batch. Show both words |
Illustrative worked example: a budgeting app and a Gulf bank
Everything here is invented. Wadi Crest Bank is a fictional Gulf bank. Pennyfold is a fictional budgeting app. Imogen Veldt is the bank’s digital product lead, and Teodor Kessler is the integration engineer on its older core.
Pennyfold asks for 12 months of transactions from a customer’s current account and savings account, with consent running 12 months. The current account sits on a newer platform. The savings account sits on an older core that posts in a nightly batch. Its interface returns the balance as of the last close and transactions through the previous business day.
Imogen Veldt makes four decisions with Teodor Kessler. The account list shows both accounts, and the savings row reads “Balance as of last night’s close”. The review screen says Pennyfold will see savings transactions up to the previous business day, plus the 12-month end date and a line on where to stop the sharing. If the older core misses the timeout while building the list, the screen says savings is unavailable right now and offers the current account alone. The consent record lists only the accounts the customer selected. On the dashboard, the Pennyfold row shows both accounts, “Active”, the end date and a “data last shared” time for each, logged at the API layer.
Three weeks later the customer taps “Stop sharing”. The status changes to Revoked at once, because the consent record is outside the batch. The history keeps the row. The message says Pennyfold can no longer get new data, and that data it already holds stays with Pennyfold, so the customer should contact the provider about it. That last line follows the UK guidelines’ advice that banks tell customers to contact the provider.
Where do these defaults stop working?
The sources are a regulation, guidelines, an API specification, a regulator’s policy statement and one bank’s customer page. None measures whether a screen changes completion or complaints. The UK material comes from a different regime. We could not read the UAE operator’s detailed standards for the bank’s authorization page from an official source, so we did not rely on them, and you should obtain the current version before designing. We did not read Saudi or Bahraini rules. Corporate and joint accounts, insurance data and minors are outside this guide.
What can you produce now?
Five things, before design starts:
- The state table filled in for your accounts, with what each system can record and how fast.
- A list of the accounts and data types your core can return today, with the age of each answer.
- Review-screen wording: purpose, accounts, data, end date, how to stop.
- A dashboard spec: row fields, detail page, history and the revocation message.
- A test list: timeout, one account missing, revoking during a data call, expiry, and a payment that is accepted but not booked.
To plan what the core can and cannot return, see our 8-week pilot plan and legacy constraint map. For wording that stays honest about batch timing, see our guide to pending items and cut-off times on a legacy core.
