Open Bankingالمصرفية المفتوحة Open Banking

Open banking is letting an app read your bank account data, with your permission, without handing it your password.

Rather than the app logging in as you, the bank grants it a narrow permission: these accounts, this period, read only. And you can withdraw that permission whenever you like.

A guest key is valuable because of the doors it cannot open, not because of its shape.

Why not just give the app my banking password?

This is exactly what used to happen a few years ago, and it is worth knowing why it ended.

Budgeting apps used to ask for your online banking username and password. They would then log in as you, read the screen, and extract your transactions. The technique is called screen scraping.

Think about what that means. The app holds the keys to your entire house. Your bank cannot tell you and the app apart, because the login happened in your name. If the app wanted to move your money, it could. If its database leaked, thousands of banking passwords leaked with it. And if you disputed a transaction, the bank would say it was made with your key.

On top of that, banks redesign their pages, and the app would break without any reason a user could understand.

Open banking is the answer to all of it: instead of handing over your key, you ask the bank to open one specific door for one specific app. You set what it may see, for how long, and you can close it from your banking app rather than from the other one.

The old doorway was a password

Before a proper access route existed, apps used screen scraping (كشط الشاشة). An app asked for your online-banking username and password. It then logged into the bank as if it were you and read numbers designed for a human-facing page. It might repeat the process each night to collect new transactions.

This gave the app much more authority than its product needed. A budgeting tool wanted a balance but received a secret capable of opening transfers, settings, and messages. If the app leaked that secret, the bank struggled to distinguish its login from the customer's. A redesign of the bank's page could also break the connection when fields and buttons moved.

Revocation was equally poor. A customer could not invalidate access for one app at the bank. They had to change the password and then repair every service that shared it. Sharing the secret might also breach bank terms, making responsibility harder to establish after an unauthorised transaction.

Calling the process a "secure link" does not stop it from being scraping. If an app asks you to type your bank password inside the app, treat that as a red flag. A sound connection redirects you to the bank or an approved authentication channel. The third-party app never sees the bank password or login code.

An interface that asks instead of impersonating

Open banking replaces the fragile page with an application programming interface, or API (واجهة برمجية). It is a defined doorway through which software requests data or starts an action. An app sends a structured request such as "provide this account's transactions since the first of the month." The bank returns agreed fields without the app pretending to be its customer.

The interface is not exposed indiscriminately to the internet. A provider meets regulatory and technical requirements, registers a digital identity, and connects through encrypted channels. The bank verifies the provider and its permitted type of activity. It then binds the request to explicit customer consent (التفويض).

Consent (التفويض) is not a broad term accepted when the app was installed. It grants a named app a defined purpose, specific accounts or data, and a limited duration. The customer needs to understand the result before pressing approve, rather than discover it inside lengthy terms.

A useful consent screen answers four questions. Who requests access? Which account will it reach? What data or action is requested? When will access expire? If one answer is unclear, the guest key may open more than it should.

Reading is not moving money

Open banking contains two service families with different risk. The first is account information services. A regulated app reads balances or transactions that you approved. A budgeting app might combine accounts from two banks. A lender might analyse a consenting shop's cash flow to assess repayment capacity.

Information access does not move a riyal by itself. It can still reveal your salary, rent, medical spending, shopping locations, and travel habits. Reading is not low-risk merely because funds remain in place. A year of transaction history can expose more of your life than one leaked card number.

The second family is payment initiation services. An app asks your bank to make a payment to a specified recipient. The bank displays the amount and destination and authenticates you through the required journey. It then executes from the account without the app holding your funds as wallet value.

An error here can have an immediate financial effect. If an attacker changes the recipient, money may reach the attacker. If the system repeats a request, the customer may pay twice. Payment messages therefore need an idempotency identifier, clear confirmation of amount and destination, and records showing who requested the action and when.

The two powers should not hide behind one vague button. An expense-comparison app does not need authority to move funds to draw a chart. A shop initiating payment does not need your entire transaction history to receive its price. The least necessary scope limits damage if consent is misused.

The consent journey is the product

Connection begins when the customer selects a bank in the app. The app sends a request describing purpose, scope, and duration. The customer moves to the bank's channel, where the bank authenticates them and presents permission details. After approval, the bank issues a limited access token to the app.

The token does not contain the bank password. It is a separate technical secret that can be constrained and revoked. It may permit one account but not another. It expires or requires renewed consent under the applicable framework. If stolen, its authority remains limited to the scope for which it was issued.

Customers need a clear place to review active connections. They should see the app, accounts, data, expiry, and most recent access. They must be able to revoke consent without calling support or deleting their whole account. The bank then rejects later requests using the revoked token.

Revocation does not necessarily erase data previously obtained for a lawful purpose. An app may need to retain records required by financial rules or an existing contract. It does stop new collection or initiation under that consent. The provider's data policy should explain what is deleted, what remains, and why.

Consent expiry also differs from a temporary technical failure. When permission expires, the app needs new consent and must not work around it by asking for the password. When the bank is briefly unavailable, the app should report an outage rather than claim that the customer revoked access.

Trust needs a traceable record

Each participant records part of the journey. The app records the requested scope and displayed purpose. The bank records consent, authentication, and the token issued. The interface records requests, responses, and errors. When a customer complains, these logs reconstruct events without guesswork.

"The customer agreed" is not enough without the actual consent record. A customer might approve three months of history while a bug returns two years. They may approve a personal account while the system sends data from a joint account. Review must compare execution with documented scope, not with good intentions.

An information provider should also minimise retained data. A product calculating monthly spending totals may not need every transaction description for years. If it sends data to an analytics company, the stated purpose and consent need to cover that flow. One approval cannot quietly become permanent permission for sale and reuse.

A payment initiator needs controls against destination substitution and repetition. It binds the recipient and amount to the request identifier shown to the customer. An idempotency key stops a retry from executing the same message twice. Status must accurately distinguish pending, successful, and failed, because a careless "try again" button can create a second payment.

Open banking in Saudi Arabia

SAMA launched the Saudi Open Banking Program as part of the Kingdom's Fintech Strategy. Its framework combines use cases, business rules, technical standards, and customer-experience guidance. It covers Account Information Services and Payment Initiation Services. The Open Banking Lab lets banks and fintech companies test whether their interfaces conform before launch.

"Open" does not mean that bank data is generally exposed. Access passes through an eligible provider, a defined interface, provable consent, and security controls. The bank remains custodian of the account and its authentication. The app remains responsible for using authority only for the displayed purpose and protecting received data.

You can inspect any open-banking journey through five screens: bank selection, purpose and scope, bank authentication, success confirmation, and consent management. If revocation is missing, customer control is incomplete. If the app itself presents a field for your bank password, stop the journey.

A product team should measure more than successful connections. It can measure whether customers understood the scope, how often consent exceeded the product's need, revocation time, data errors, and duplicate payment requests. A risk team should challenge an app that requests every account merely because doing so is easier to build. Developer convenience is not a valid reason to enlarge a customer's key.

Open banking separates three roles once blurred inside one app. The bank keeps the account and executes instructions. The service provider builds a new use. The customer grants permission and can withdraw it. Their common link is not a shared password but a documented technical agreement defining boundaries.

This model can later extend beyond banking. A customer might share insurance or investment data in a similar way. The principle remains stable: innovation does not require collecting more secrets. It requires granting the smallest authority needed for a clear job, then allowing it to end.