Getting structured data out of an SNB Mobile account, the consented way

Saudi National Bank was assembled in 2021 from the merger of National Commercial Bank and Samba Financial Group — reported by Arab News as the Kingdom's largest lender, with assets put at over SAR 900 billion at formation. SNB Mobile (also carried under the bank's older "AlAhli" brand) is the retail and SME front end those customers log into. The reason this app is reachable at all is that Saudi Arabia runs a live Account Information Service regime: the Saudi Central Bank, SAMA, issued the first Open Banking Framework focused on AIS, and banks were expected to be ready in early 2023. That is the spine of the route here. Not protocol guesswork — a regulated consent flow a licensed bank like SNB has to support.

The bottom line is short. An SNB customer's everyday banking data — what they hold, what moved, what is scheduled — is reachable through a SAMA-governed consent rather than through fragile interface scraping, and that is the route worth building on. We treat protocol analysis of the app's own traffic as a fallback for surfaces the consent scope does not yet expose, not as the primary plan.

How a third party reaches an SNB account holder's data

Three routes genuinely apply to this app. They are not equal.

Consented AIS under the SAMA framework — recommended

The customer authenticates inside SNB Mobile or AlAhli online and grants a third party read access to accounts, balances and transactions for a defined period. This is durable: it is the route SAMA designed the bank to support, the security profile is aligned with FAPI (mutual TLS, signed request objects, managed consent), and a screen redesign in the app does not break it. Effort sits in the consent lifecycle and certification, not in reverse engineering. We set up the client against the SAMA Open Banking Lab and the live consent flow as part of the engagement.

Authorized protocol analysis of the app's own interface

Where a needed surface is not covered by the consent scope, we map the app's authenticated traffic under the customer's authorization — the token and request chain it uses for, say, the Tadawul cash-transfer screen or SADAD biller lookups. Higher maintenance, because it tracks the app's release cycle, so we keep it scoped to the gaps the regulated route leaves.

User-consented credential access

A narrower fallback for one-off pulls where a customer authorizes access against their own login. Workable, least durable, and we only recommend it when neither of the above fits the timeline.

For almost every SNB integration the consented AIS route is the one to build the system around, with protocol analysis filling specific gaps. We say which gaps after scoping, because it depends on exactly which surfaces you need.

What SNB Mobile holds, surface by surface

A consented balance-and-transactions call, sketched

This is the shape of the regulated route against an SNB account. Paths and claim names are illustrative; the exact contract is confirmed against the SAMA Open Banking Lab during the build.

# 1. Create the account-access consent; customer then authenticates in SNB Mobile / AlAhli
POST /open-banking/v1/account-access-consents
  Permissions: [ReadAccountsDetail, ReadBalances, ReadTransactionsDetail]
  -> 201 { "consentId": "OBC-...", "status": "AwaitingAuthorisation",
           "expiry": "2026-08-19T00:00:00+03:00" }

# 2. After consent granted (OAuth2 / FAPI: mutual TLS + signed request object)
GET /open-banking/v1/accounts
  Authorization: Bearer <access_token>
  x-fapi-interaction-id: <uuid>
  -> 200 { "Data": { "Account": [
       { "AccountId": "SA..-masked", "Currency": "SAR",
         "AccountType": "Personal", "AccountSubType": "CurrentAccount",
         "Nickname": "<customer-edited short name>" } ] } }

# 3. Pull dated transactions for one account
GET /open-banking/v1/accounts/{AccountId}/transactions?fromBookingDateTime=2025-05-01
  -> 200 { "Data": { "Transaction": [
       { "BookingDateTime": "2026-05-12T09:31:00+03:00",
         "Amount": { "Amount": "250.00", "Currency": "SAR" },
         "CreditDebitIndicator": "Debit",
         "TransactionInformation": "SADAD bill / local transfer" } ] } }

# 4. Consent lapsed or revoked in-app
  -> 403 { "Code": "Forbidden", "Message": "Consent expired or revoked" }
  # handler: re-trigger consent, never silently retry the token

What lands at the end of the build

Tied to the surfaces above, not a generic kit:

• An OpenAPI/Swagger specification for the consented account, balance and transaction calls as they apply to SNB.
• A protocol and auth-flow report: the OAuth2/FAPI consent grant, token refresh, and the mutual-TLS posture SAMA requires.
• Runnable source for the key endpoints in Python and Node.js — consent creation, account list, paged transaction pull, transfer-status read.
• A normalized schema that flattens SNB accounts (including migrated NCB/Samba ones) into one account/transaction model.
• Automated tests covering the consent lifecycle, expiry and the 403 revocation path.
• Interface documentation plus data-retention and consent-record guidance aligned to the PDPL.

SAMA consent, the PDPL, and what that constrains

The regulator is the Saudi Central Bank (SAMA), and the instrument is its Open Banking Framework — AIS in the first release, Payment Initiation in the second release issued in September 2024 per SAMA's announcement. For a data-read integration with SNB, AIS is the relevant part. The customer's consent is explicit, informed and revocable under the Saudi Personal Data Protection Law; it carries a scope (which permissions) and an expiry. Two things follow directly. Access is read-bounded to the permissions the customer granted, so we design pulls to stay inside that scope. And consent ends — by expiry or revocation in the app — so the sync re-prompts rather than failing quietly. We keep consent records and request logs, work under NDA where the customer requires it, and minimize stored fields to what the integration actually uses.

Engineering judgments we bake into the SNB build

Things this specific app forces us to handle, which we account for so they are not surprises later:

• Dual brand, split surfaces. The bank trades as both "SNB" and legacy "AlAhli", and the investment arm (SNB Capital / AlAhli Tadawul) is a different system from retail banking. We map which surface actually owns each domain so an "investments" request is not pointed at the banking interface — the Tadawul screen in SNB Mobile only moves cash; holdings are scoped separately if you need them.
• Post-merger account identifiers. Customers were migrated from NCB and Samba onto one platform. We normalize legacy account-number formats and dual-brand identifiers so a consent issued on a migrated account resolves to a single stable record.
• SAMA security profile. We build the client to the FAPI-aligned profile — mutual TLS, signed request objects, the consent-grant and refresh lifecycle — and design the schedule around the consent window so it does not silently lapse. Access is arranged with you during onboarding; the build runs against the SAMA Open Banking Lab or a consenting live account.
• Frequent app updates. SNB ships feature changes often (My Family, receipt redesigns, inline SADAD pay). For the protocol-analysis fallback, the handover includes a check that re-confirms mapped fields against the live interface before a release depends on them.

Where integrators put this to work

• A personal-finance app showing one consolidated balance across SNB, Al Rajhi and Riyad — consented AIS pulls normalized to a single schema.
• An SME bookkeeping tool reconciling SNB transactions and SADAD/government payments against issued invoices.
• A lender pulling a consented window of transaction history for affordability scoring before extending credit.
• A family-finance product surfacing the "My Family" child-account allowance schedule for guardianship oversight.

Cost and how to start

A working SNB integration — the consented AIS client, the normalized account/transaction schema, tests and interface docs — lands within one to two weeks of scoping. From there it works one of these ways. Source-code delivery starts at $300: you get the runnable source and documentation, and you pay after delivery, once it works to your satisfaction. Or take the hosted API: we run the endpoints, you call them and pay per call, with no upfront fee. Send the app name and what you need from its data through our contact page and we will scope the SNB route with you.

What was checked, and against what

Checked in May 2026 against the Saudi Open Banking program material, SAMA's framework announcements, and SNB's own digital-banking and store listings to confirm the data surfaces and the regulated route. Primary sources:

• Saudi Arabia Open Banking program portal
• SAMA — issuance of the Open Banking Framework
• SPA — SAMA's second Open Banking release (Payment Initiation)
• SNB / AlAhli Mobile banking feature page

Mapped by the OpenBanking Studio integration desk — May 2026.

Screens from the app

The Saudi banking apps around this one

Same market, same kind of consented data — useful context for anyone consolidating more than one Saudi bank:

• Al Rajhi Mobile — the world's largest Islamic bank's retail app; current/savings accounts, transfers and cards, and a common second account held alongside SNB.
• Alinma Bank — a fully Islamic, digital-first bank with retail accounts and transfers.
• Riyad Bank — retail accounts plus multi-currency sub-accounts often used by the same expat customers.
• Bank Albilad — Shariah-compliant retail accounts and payments.
• Arab National Bank (ANB) — retail accounts, cards and transfers.
• Bank AlJazira — retail and Shariah-compliant accounts.
• STC Bank — a payments-led digital bank with wallet-style balances.
• D360 Bank — a digital-only bank focused on zero-fee accounts and micro-lending.

All of these sit under the same SAMA Open Banking regime, which is what makes a single consolidated integration across them feasible.

Questions integrators ask about SNB Mobile

Does one SNB consent cover accounts that were migrated from NCB or Samba?

Yes. SNB customers were moved onto a single platform after the NCB and Samba merger, so a consent issued for a customer resolves their accounts regardless of which legacy bank they came from. We normalize the legacy account-number and dual-brand identifiers during the build so a migrated account maps to the same record every time.

Can you reach SNB Capital or Tadawul portfolio holdings through SNB Mobile?

Only partly. Inside SNB Mobile the Tadawul screen moves cash to a brokerage portfolio; position-level holdings and trade data live in SNB Capital's own surface (AlAhli Tadawul), which is a separate integration we scope on request rather than reaching it through the retail banking interface.

Which Saudi regulator governs this, and what does an SNB account holder actually consent to?

The Saudi Central Bank (SAMA) Open Banking Framework governs it. The customer grants explicit, informed and revocable consent — typically read access to accounts, balances and transactions for a fixed window — under the Saudi Personal Data Protection Law. We record consent scope and expiry and re-prompt rather than retrying when it lapses.

Do you build against a live SNB account or a sandbox?

Either works. The client work runs against the SAMA Open Banking Lab certification environment or a consenting live SNB account; we arrange that access with you during onboarding so the build is verified against the real consent and token lifecycle, not a guess at it.