Pulling balances, statements and payroll out of SAB iCorp

Twelve months of business-account statements, an OTP that signs into the matching web portal, payroll authorization on top of WPS files, and an entitlement layer shared between the app and the desktop browser — that is the surface SAB iCorp puts in front of a corporate signer. The integration job is shaped by that shape, not by a generic "mobile banking" template.

For a Saudi-resident corporate, the natural spine is SAMA-licensed AIS for the account-information pieces, with authorized interface integration filling in the payroll, instruction-authorization and admin surfaces that sit outside AIS scope. That is what we build, in source code or as a hosted endpoint the customer's stack calls.

Data the app surfaces

Domains named the way SAB iCorp names them, with the bank-side origin and the practical reason an integrator would want each one.

Routes into the iCorp ledger

Three routes apply here. The right answer is usually a blend.

For most corporates we recommend the second route as the spine — it covers the payroll and authorization surfaces a finance team actually wants — and layer SAMA AIS over the account-information slice as soon as the customer's TPP arrangement is in place. The credential route is the bridge while that happens, not the destination.

Working example — OTP exchange and the twelve-month statement window

Illustrative request and response shapes from an authorized integration build; field names confirmed during the build for the customer's environment, not republished vendor specifications.

POST /icorp/auth/totp/exchange
{
  "device_token": "<device-bound, issued at registration>",
  "otp": "######",
  "user_ref": "<corporate signer id>"
}
→ 200 OK
{
  "session": "<short-lived bearer>",
  "signer": "MAKER",          // resolved from SAB entitlements
  "entitlements": ["VIEW_BAL", "STMT_12M", "PAYROLL_SUBMIT"]
}

POST /icorp/accounts/statement
Authorization: Bearer <session>
{
  "account_iban": "SA##XXXXXXXXXXXXXXXXXXXXXX",
  "from": "2025-06-01",
  "to":   "2026-05-29",          // up to the in-app twelve-month horizon
  "page": 1, "page_size": 200
}
→ 200 OK
{
  "lines": [
    { "value_date": "2026-05-28", "narrative": "WPS PAYROLL APR-26",
      "amount": -184320.00, "ccy": "SAR", "ref": "WPS-2026-04-30-7741" },
    { "value_date": "2026-05-26", "narrative": "INWARD MT103",
      "amount":   45000.00, "ccy": "SAR", "ref": "FT26146CXXXX" }
  ],
  "next_page": 2
}

// Error surfacing the integration must handle cleanly
→ 401 { "code": "TOKEN_REREG_REQUIRED" }   // device re-registration
→ 403 { "code": "ENTITLEMENT_MISSING", "needed": "STMT_12M" }
→ 409 { "code": "MAKER_CHECKER_PENDING", "queue": "PAYROLL_APR-26" }

What we hand over for SAB iCorp

Concrete artefacts. Nothing vague, nothing optional-sounding.

• An OpenAPI specification describing the surfaces we wrap — balances, statements, instruction status, payroll submission and read-back, the auth and entitlement model — so the customer's stack consumes a stable shape regardless of which underlying route serves any given call.
• A protocol and auth-flow report covering the OTP / device-token / session chain, the maker-checker queue states, and how WPS rejection codes propagate. Roughly twelve to twenty pages, written so an in-house engineer can take over the integration without further calls with us.
• Runnable source for the key endpoints in Python and Node.js: the TOTP exchange wrapper, the paginated statement pull with the twelve-month window enforced server-side, the WPS submit-and-poll cycle, and the entitlement-aware error mapping.
• An automated test suite — contract tests against captured fixtures and a small smoke run against the customer's own consenting account, including the device re-registration and entitlement-missing paths so they are not surprises later.
• Interface documentation plus data-retention and consent-record guidance shaped to SAMA's Open Banking Framework and to standard NDA terms the bank's procurement function expects.

SAMA and the consent that backs it

SAMA — the Saudi Central Bank — published the first release of its Open Banking Framework in November 2022, focused on AIS, and followed up with the second release covering Payment Initiation Services in September 2024. Clyde & Co reported in March 2026 that SAMA had moved beyond the regulatory sandbox into formal licensing of open-banking providers, with two firms named in the first wave. The technical security profile is FAPI-aligned: mutual TLS, signed request objects, FAPI consent management, and Open Banking Lab certification on the way in.

For SAB iCorp the consent that matters is the one the corporate signer grants, captured against the entitlement set their SAB login already carries. Scope and expiry follow the SAMA model; the integration logs every call against the consent that authorized it, and revocation reaches the read paths the same business day. Compliance posture across the build is straightforward: authorized routes only, NDAs in place, data minimized to the fields the caller asked for.

Build notes that shape the work

Three things about SAB iCorp specifically that we factor into every build rather than leave for the caller to trip over.

• Entitlements are shared between the iCorp app and the web portal. Access to a given service depends on the user's entitlement set, and SAB documents that the set is common across mobile and portal. We map signer, maker and checker roles into the integration so the customer's existing approval matrix is mirrored, not flattened into a single super-user that would not exist in their real ops.
• The OTP is generated on the registered device, not server-side. The mobile app is the soft token; deactivating and re-registering a token is a normal in-app flow. We model the re-registration path explicitly so a new handset, an entitlement reset or a token-reactivation does not turn a scheduled job into silent 401s.
• WPS payroll is file-based and runs through a checker queue. The customer uploads the WPS file with the correct payroll details per employee, and approval lives downstream. The integration wraps the upload and the status-polling so callers see WPS rejection codes the same day, with the relevant queue surfaced — not a week later when payroll fails.

What we checked, and where

This page reflects the public SAB iCorp surface and SAMA's published open-banking material as of 2026-05-29. Specific deep links we worked from:

• SAB — SAB iCorp product page (feature set, entitlement model, OTP role).
• SAMA Open Banking Policy (PDF) (regulator's published framework).
• SAMA — second release of the Open Banking Framework (PIS phase, September 2024).
• Google Play — SAB iCorp listing (described feature set, retained com.SABBcorp package id per the store listing).

OpenBanking Studio integration desk — mapping reviewed 2026-05-29.

Other Saudi corporate banking apps in the same lane

For ecosystem context, not ranking — these are the apps a finance team is most often weighing alongside SAB iCorp when scoping a multi-bank corporate integration.

• Al Rajhi Business — Al Rajhi Bank's corporate companion, with bulk payroll, signer hierarchies and SME onboarding.
• SNB Mobile Pro Corporate — Saudi National Bank's commercial channel covering similar account aggregation and WPS payroll flows.
• Riyad Business — Riyad Bank's corporate mobile, multi-account dashboards and maker / checker authorization.
• BSF Business — Banque Saudi Fransi's corporate channel with treasury, trade-finance and account surfaces.
• Alinma Tijari — Alinma Bank's commercial mobile aimed at SME and corporate customers.
• ANB Net Corporate — Arab National Bank's corporate channel for transfers, payments and statements.
• Bank Albilad Tijara — Albilad's commercial mobile with payroll and bulk-payment authorization.
• SAIB Corporate — Saudi Investment Bank's corporate companion, similar accounts-and-payments scope.

Same regulator, similar entitlement-and-signer pattern across the lot. An integration designed properly for SAB iCorp is normally repointed at any of these in days rather than weeks.

Questions integrators usually arrive with

Does the OTP-token side of SAB iCorp have to be recreated in the integration?

The mobile app generates the OTP that signs into the web portal and authorizes transactions, so the device-bound soft-token chain sits in the path. We model it explicitly during the build: registration, re-registration on a fresh handset, and the corresponding session and entitlement set on the bank side. The caller does not have to reimplement it themselves.

Will going through SAMA AIS surface the same twelve-month statement window the in-app view shows?

AIS scope in Saudi Arabia is set per the SAMA Open Banking Framework and the consent the corporate signer grants, not by the in-app retention rules. For balances and account information the AIS path is the most durable; where the SAB-side history extends further back than the AIS scope returns, we layer that in through authorized interface integration so the caller still sees the full twelve months.

Can the integration drive payroll, or is it read-only?

WPS payroll is the part of SAB iCorp that turns a CSV or WPS file plus a signer's authorization into a salary run. We can wrap that flow — upload, maker submission, checker approval, status polling and rejection-code surfacing — alongside the read paths, so callers get the full audit-and-authorize cycle, not only the read side.

How does the SME-versus-corporate split change the build?

SAB iCorp covers SME, local-corporate and public-sector segments under one app, and the access a given login has is decided by the entitlement set behind it. We scope the integration to the actual signer / maker / checker matrix the customer holds, rather than assuming a flat single-role login that does not exist in practice.

Pricing for the work is the simple part. Source-code delivery starts at $300, with payment due only after the build clears acceptance against the customer's own consenting account. The hosted-endpoint option bills per call, with no upfront fee. Either way the build runs on a one-to-two-week cycle. To start a scoping conversation, reach the integration desk through /contact.html with the entitlement set you need covered and the surfaces — accounts, statements, payroll, instructions — that matter to your stack.