How SAIB Mobile account data is reached under SAMA's framework

Saudi Central Bank (SAMA) made Account Information Services a regulated route to bank account data in the first release of its Open Banking Framework in November 2022, per SAMA's published framework releases. The Saudi Investment Bank is a long-established Saudi joint-stock bank, and SAIB Mobile — the retail app it ships as part of its Flexx digital banking line, package com.saib.mobile.retail per its Google Play listing — sits squarely inside that regime for its current- and savings-account data. That single fact sets the spine of any integration here, so this brief starts with the rules and works outward to what an integrator actually gets back.

Where SAMA's rules put SAIB account access

SAMA's framework is staged. The first release, November 2022, covered Account Information Services (AIS); the second, September 2024, added Payment Initiation Services (PIS) — both dates per SAMA's framework-release announcements. The technical standards are aligned with the FAPI security profile: mutual TLS, signed request objects, and managed consent. From March 2026, per Clyde & Co's note on the new regime, SAMA moved open banking out of the sandbox into formal licensing, treating it as a fully supervised activity for which a firm must hold a SAMA licence; Lean Technologies was reported as the first licensee.

For SAIB this means current and savings account information — balances, transaction history, account details — is reachable over consent-bound AIS APIs by a licensed account information service provider. Consumer data here is governed by the Saudi Personal Data Protection Law: access needs explicit, informed consent, scoped and time-limited, and revocable by the customer at any point. We treat that consent record, its scope and its expiry as first-class objects in the integration, not an afterthought.

Authorized ways into the account data

Three routes apply to SAIB Mobile, and they are not interchangeable.

Regulated AIS via a licensed AISP

Account and transaction data over SAMA's standardized, FAPI-secured APIs with customer consent. Durable, audited, and the cleanest legal footing. It reaches the AIS-eligible surfaces only, and it presumes the consuming entity holds or is obtaining a SAMA open-banking licence. Onboarding to the scheme and the consent flow is set up with you as part of the engagement.

Authorized protocol analysis of the Flexx Touch session

Reverse engineering of the app's own traffic, under your written authorization, for the surfaces AIS does not cover — loyalty points, card controls, finance products, investment portfolio. Wider reach than AIS, more sensitive to front-end change, and the realistic path before a licence is in hand. We run it against a consenting account or a test profile arranged with you.

User-consented session access

Where a customer authorizes access to their own Flexx Touch or Flexx Click session, the same protocol map drives a per-user pull. Useful for aggregation products that hold their own user relationships. Effort is low once the protocol report exists; durability tracks the app's release cadence.

For a SAIB build we would put the regulated AIS path at the centre for accounts and transactions wherever the consumer is or can become a licensed AISP, and run authorized protocol analysis alongside it for the loyalty, card and investment screens that fall outside the AIS data set. That split is the recommendation, and the reasoning is simple: one route is durable but narrow, the other is broad but needs maintenance, and SAIB's surface mix needs both.

What an AIS account-data call looks like

# Illustrative shape, confirmed against the live surface during the build,
# not transcribed from a public document.

# 1) SAMA-AIS account list  (FAPI: mutual TLS + signed request,
#    consent-bound bearer token)
GET https://<saib-ob-host>/open-banking/v1/accounts
    Authorization: Bearer <consent_access_token>
    x-fapi-interaction-id: 7d3c-...
  -> 200
     { "Data": { "Account": [
         { "AccountId":  "SA__-current",
           "AccountType":"Personal",
           "Currency":   "SAR",
           "Nickname":   "Flexx current" } ] } }

# 2) Statement / transactions for one account
GET .../open-banking/v1/accounts/{AccountId}/transactions
        ?fromBookingDateTime=2026-01-01
  -> 200
     { "Data": { "Transaction": [
         { "Amount": { "Amount":"450.00","Currency":"SAR" },
           "CreditDebitIndicator":"Debit",
           "BookingDateTime":"2026-02-11T09:14:00+03:00",
           "TransactionInformation":"SADAD bill payment" } ] } }

# 3) Non-AIS surfaces (loyalty ledger, card controls): authorized
#    protocol analysis of the Flexx Touch session. Biometric quick
#    login is device-bound; we model the username/password + OTP
#    exchange and refresh the token before SAMA's consent window lapses.
POST https://<flexx-app-host>/auth/v3/token   { grant_type:"refresh" }
  -> 200 { access_token, expires_in: 900, refresh_token }
GET  .../loyalty/points/summary
        Authorization: Bearer <access_token>
  -> 200 { "pointsBalance": ____, "tier":"...", "redeemable": true }
      

Field names and hosts are placeholders until the build pins them against the real surface. The point of the snippet is the shape: a consent-bound AIS read for accounts and statements, and a separate refreshed-token read for the screens SAMA's data set does not include.

What you receive at the end

The hand-over is built around SAIB's actual surfaces, not a generic kit:

• An OpenAPI/Swagger specification covering the account list, transaction and statement reads, and the non-AIS endpoints for cards, finance products, investments and the loyalty ledger.
• A protocol and auth-flow report: the Flexx Touch login chain (username/password and OTP), token issuance and refresh, the consent lifecycle on the AIS side, and how the two are kept in step.
• Runnable source for the key endpoints in Python and Node.js — account pull, dated transaction query, card and loyalty reads — with retry and error handling.
• Automated tests against recorded fixtures so a SAIB front-end change shows up as a failing test, not a silent gap.
• Interface documentation plus data-retention and consent guidance written against PDPL and SAMA's framework.

Account surfaces inside SAIB Mobile

Things we plan around on this build

A few specifics about SAIB shape the engineering, and we account for each on our side:

• SAIB exposes both AIS-eligible surfaces (accounts, balances, transactions) and surfaces outside SAMA's AIS data set (loyalty points, IPO and fund subscriptions, card controls, finance products). We build the regulated AIS calls and the authorized protocol-analysis calls as separate, independently maintainable modules so a scheme change on one side does not disturb the other.
• Flexx Touch offers username/password, Face ID, Touch ID, passcode and saved-credential quick login. The biometric paths are device-bound and not replayable server-side, so we model the session on the password and OTP exchange plus token refresh, and we design the refresh around SAMA's consent-expiry window so a long-running sync does not silently drop mid-cycle.
• Transfer rails differ — SARIE for domestic, SWIFT for cross-border, SADAD for bills and government fees — and card types (mada, travel, credit) surface differently again. We normalise them into one schema and keep a checked re-validation step in the maintenance plan for when the app front end shifts.

Scheme onboarding, the sponsor or test account, and the authorization paperwork are arranged with you during onboarding; none of it is something you need to clear before we begin mapping.

Where teams take an integration like this

• A personal-finance app pulling SAIB current-account transactions over AIS to feed multi-bank budgeting alongside other Saudi banks.
• An SME lender ingesting dated statement data with consent for affordability and limit decisions.
• A wealth dashboard combining the SAIB investment portfolio and fund subscriptions with holdings held elsewhere.
• A loyalty aggregator reading the SAIB points ledger so members see and redeem rewards from one place.

Other Saudi banking apps in the same picture

An integrator rarely wants one bank in isolation. The same SAMA AIS plumbing and the same protocol-analysis discipline carry across the market, so these names recur on the same projects:

• Al Rajhi Mobile — the largest Islamic bank's app; accounts, cards and Shariah-compliant finance, a frequent first add to any aggregation.
• SNB Mobile — Saudi National Bank, broad retail and wealth data across one of the Kingdom's biggest customer bases.
• Riyad Bank — retail accounts, cards and financing with a growing digital surface.
• Alinma — Shariah-compliant retail and corporate banking with active transaction data.
• Bank Albilad — retail accounts, transfers and Enjaz remittance flows.
• Banque Saudi Fransi — accounts, cards and finance products with similar AIS exposure.
• Arab National Bank — retail and payroll-linked account data common in employer aggregation.
• STC Bank — a mobile-first wallet and account model with payment-heavy data.
• D360 Bank — a branchless digital bank whose data lives entirely in-app.

App screens

How this brief was put together

The surface map comes from SAIB's own product pages and store listing read in May 2026, cross-checked against SAMA's open-banking framework releases and the March 2026 licensing change. Primary sources opened: SAIB Mobile / Flexx apps page, the official Saudi open banking portal, and Clyde & Co on SAMA's 2026 licensing regime. Where a value is not publicly disclosed it is left as a placeholder rather than guessed.

OpenBanking Studio integration desk — mapping reviewed May 2026.

Questions integrators ask about SAIB Mobile

Does SAIB Mobile fall under SAMA's Open Banking Framework, and what does that change?

Yes. SAIB is a Saudi bank, and SAMA's Open Banking Framework made Account Information Services a regulated route to current- and savings-account data in its first release (November 2022, per SAMA's framework releases). For an authorized AISP, that means balances and transactions come over FAPI-secured, consent-bound APIs rather than scraped sessions, with consent that is explicit, time-bound and revocable under the Saudi Personal Data Protection Law.

Can the loyalty points and investment-portfolio screens be reached, or just current accounts?

Current and savings accounts, balances and transactions sit inside the SAMA AIS data set. The loyalty points ledger, IPO and fund subscriptions, and card-control screens are SAIB-specific surfaces outside that set; we reach them through authorized protocol analysis of the Flexx Touch session under your authorization, and normalize both into one schema.

How do you handle the Flexx Touch login — biometrics, passcode, saved credentials?

Face ID, Touch ID, passcode and saved-credential quick login are device-bound shortcuts that are not replayable server-side. We model the session on the username/password plus OTP exchange and the token refresh behind it, and document the full auth-flow chain in the protocol report so the integration can re-authenticate without a human at the device.

If we are not a SAMA-licensed AISP yet, can you still deliver a working SAIB integration?

Yes. The authorized protocol-analysis route runs under your authorization against a consenting account and does not wait on a licence; the regulated AIS path becomes the spine once the SAMA licence is in place, and the code is built so that switch is a configuration change, not a rewrite. Tell us the app and what you need at https://openbankingstudio.com/contact.html.

Engagements run one of two ways. Take source-code delivery and we build the SAIB integration, hand over the runnable code, the OpenAPI spec, the tests and the interface write-up, and you pay from $300 only after delivery, once it works for you. Or skip the build and call our hosted endpoints instead, paying per call with nothing upfront. Either way the working cycle is one to two weeks. Give us the app name and what you need from its data on the contact page and we take it from there.