Getting account data out of the Boubyan App

Per Global Finance reporting, close to all of Boubyan Bank's customer transactions now move through this app rather than a branch or the web. That makes it the single place where a Kuwaiti customer's accounts, cards, deposits, Islamic financing and transfers exist as structured records. For anyone building accounting, lending, treasury or personal-finance tooling around a Boubyan customer, the app is the system of record.

Kuwait's open-banking rules are still being written, so the dependable route today is authorized interface integration against a consenting account, with the regulated path slotted in as it comes online. The data is rich. The way in is well understood. The deliverable is source you can run.

What the app actually holds

These rows track surfaces a Boubyan customer sees in the app itself, named the way the app and the bank present them.

A look at the request flow

The shape below is illustrative. Exact parameter names and headers are confirmed during the build against a consenting account, not taken from anything Boubyan publishes. It reflects the real chain the app uses: device registration, a Civil-ID-based credential step, a 6-digit SMS code, then a bearer session refreshed without re-prompting.

# Illustrative request chain — names verified during the build.

POST /m/auth/device/register
  { deviceId, appVersion, platform: "android" }      -> { deviceToken }

POST /m/auth/login
  { civilId, username, passwordEnc, deviceToken }    -> { txnRef, otpChannel: "SMS" }

POST /m/auth/otp/verify
  { txnRef, otp6 }                                   -> { accessToken, refreshToken, expiresIn }

# Subsequent calls carry the bearer token plus a device-binding header.
GET /m/accounts
  Authorization: Bearer <accessToken>
  -> [ { accountId, iban, currency, productType, clearedBalance } ]

GET /m/accounts/{accountId}/transactions?from=2026-01-01&to=2026-03-31
  -> { page, items: [ { postedAt, valueDate, amount, drCr, narrative, runningBalance } ] }

# Refresh keeps a scheduled sync alive without a fresh OTP each cycle.
POST /m/auth/refresh { refreshToken }                -> { accessToken, expiresIn }

# Error handling we wire in:
#   401            -> refresh once, then full re-auth if refresh is rejected
#   OTP throttled  -> backoff + alert; never silent-retry into a lockout
#   device unknown -> re-run device registration under the consenting user
      

What you get back

Everything below is tied to the surfaces above, not a generic kit.

• An OpenAPI/Swagger specification covering accounts, transactions, cards, deposits, financing and transfers as modelled from the app.
• A protocol and auth-flow report: the device binding, the Civil-ID credential step, the SMS one-time code, the 4-digit transaction code and the token-refresh chain, written out end to end.
• Runnable source for the key endpoints in Python or Node.js — login through refresh, then the account, transaction and transfer reads.
• Automated tests against those endpoints, including the 401-then-refresh path and OTP throttling behaviour.
• Interface documentation a second engineer can pick up without us in the room.
• Compliance and data-retention guidance shaped to Kuwait — consent records, logging, what not to store.

Authorized ways into the data

Authorized interface integration

Working from the app's own mobile traffic, under your written authorization and a consenting account, every surface the app shows becomes reachable. Effort is medium; durability tracks Boubyan's release cadence, which we keep a re-check step in maintenance for. This is the route we would run today, because it does not wait on a regime that is still in consultation.

Regulated open-banking consent

Once the Central Bank of Kuwait finalizes its Open Banking Regulatory Framework and licensing opens, a CBK-licensed provider can read the data classes the regulator defines, with the customer's explicit approval. Today that path lives in the Wolooj sandbox rather than as a general licence. We build the interim integration so it can migrate here cleanly rather than be rewritten.

User-consented credential access

For a single consenting account holder, the same flow the app uses runs with the user's explicit consent — good for a pilot, a one-off pull, or a tightly bounded feed.

Native export as a fallback

Where the app or online banking exposes statement files, those cover history but not real-time state; useful as a backstop, not as the spine of a live sync. Given the regime timeline, the first route is what we'd anchor on and the regulated path is what we design toward.

Consent and the Kuwaiti rulebook

Two regimes apply. On the banking side, the Central Bank of Kuwait issued its Open Banking Regulatory Framework as a draft for consultation in 2025 — it sets out sharing of customer data with CBK-licensed Open Banking Service Providers under explicit customer approval, with the Wolooj sandbox testing it in parallel. Because that framework is still draft, this page does not state its specific obligations as settled rules; the integration is built to adopt them once they are.

On the data side, Kuwait's Personal Data Protection Law No. 26 of 2024 sits under CITRA. As CITRA's regulation sets out, processing needs explicit consent, the data subject can withdraw it at any time, processing is minimised to what the purpose needs, and a personal-data breach is notified to CITRA within 72 hours. We operate authorized, documented or user-consented access only: consent scope is written down, every pull is logged, data is minimised to the named surfaces, and an NDA is in place where the work needs one.

Engineering notes specific to Boubyan

• Boubyan is mid-migration to a new core-banking platform, per Temenos and Fintech Futures reporting. We treat the app's backend as a moving target and keep a scheduled re-check so a core cutover does not silently break a running sync.
• The login chain binds a device, a 6-digit SMS one-time code and a separate 4-digit transaction code, with biometric unlock layered on. We model the device binding and the refresh-token lifetime so a sync holds its session across cycles; the consenting account or sandbox for that flow is arranged with you during onboarding.
• Civil ID runs through both transfers and cardless withdrawal. We map Civil-ID-keyed beneficiary and withdrawal flows distinctly from IBAN-keyed transfers, so a payout integration does not conflate the two.
• Accounts are multi-currency and financing is structured as profit rather than interest. We normalise profit-rate and maturity fields so a deposit-and-financing aggregation reads consistently next to conventional products from other banks.

Where this gets used

• An accounting platform pulls Boubyan account transactions nightly for its Kuwaiti SME clients and posts them straight into the ledger.
• A personal-finance app aggregates Boubyan balances and deposits next to other Kuwaiti banks for one net-worth view.
• A payroll tool pushes Civil-ID transfers and reconciles delivery status back into its run log.
• A lender reads financing schedules and transaction history, with the customer consenting, for an affordability check before approval.

Keeping the sync alive

Third-party listings put the app around the 6.4x release line, which is a fast cadence; we assume the front end will shift and plan the re-check around it rather than around a fixed version. Token lifetime and OTP throttling set how often a sync can poll without tripping a lockout, so the schedule is tuned to the refresh window, not to a round number. The core-platform migration is the main durability risk on the horizon, which is exactly why maintenance is part of the proposal rather than an afterthought.

Screens from the app

From Boubyan's Google Play listing — useful for reading the surfaces an integration would target.

Other Kuwaiti banking apps in the same picture

A unified Kuwait integration usually spans several of these; each holds the same kinds of account-and-transaction records behind its own login.

• NBK Mobile Banking — National Bank of Kuwait's retail app; balances, cards, transfers and instant mobile-number payments.
• Weyay — NBK's digital-only bank for younger customers, with its own account and card data.
• KFHonline — Kuwait Finance House's Islamic banking app covering accounts, financing and transfers.
• Tam — KFH's digital bank, a separate consenting-account surface.
• Warba Bank — Islamic retail and corporate banking with real-time transaction notifications.
• Gulf Bank — conventional retail banking with accounts, cards and payments.
• Nomo — Boubyan's UK-based digital bank, holding cross-border account and deposit data.
• Burgan Bank — retail and corporate accounts, cards and transfers in Kuwait.
• Al Ahli Bank of Kuwait — ABK's app, with the same account-and-card record set behind authentication.

Questions integrators ask about Boubyan

Can a licensed provider read Boubyan accounts through Kuwait's open-banking rules yet?

Not as a finished, licensable regime. The Central Bank of Kuwait issued its Open Banking Regulatory Framework only as a draft for consultation in 2025, with the Wolooj sandbox running alongside it. Until that framework and its licensing are live, the dependable route is authorized interface integration against a consenting account, built so it can move onto the regulated path once licensing opens.

Which Boubyan App surfaces hold the data integrators usually want?

Account balances and dated transaction history, card status and lifecycle, deposits and fixed deposits, Islamic financing schedules, and the full transfer set — local, international, Western Union, Civil-ID transfers and cardless ATM withdrawal. Each maps to a screen the customer already sees in the app.

How does the app's login and OTP chain affect an automated integration?

Boubyan binds a registered device, a 6-digit SMS one-time code and a separate 4-digit transaction code, with biometric unlock on top. We model the device binding and the token-refresh lifetime so a sync holds its session across cycles instead of prompting a person every run. A consenting account for that flow is arranged with you during onboarding.

We only need transfer status and cardless-withdrawal records, not the whole account — can it be scoped that tightly?

Yes. The integration is scoped to the surfaces you name, so a transfer-and-withdrawal feed is built and tested on its own without touching deposits or financing. A focused scope like that is typically a one-to-two-week build.

What we checked, and when

This mapping reads the app's described surfaces against Kuwait's banking and data rules. Checked in May 2026: the Central Bank of Kuwait's draft Open Banking Regulatory Framework press statement, the CBK Innovation Hub "Wolooj" framework document, the Temenos statement on Boubyan's core-platform modernization, and CITRA's Data Privacy Protection Regulation. Reviewed in May 2026 by the OpenBanking Studio integration desk.

Engagement is simple. You can take the source-code delivery — runnable API source plus the spec, automated tests and interface docs, from $300, invoiced only after delivery once you are satisfied — or call our hosted endpoints and pay per call with nothing upfront. Either way the cycle is one to two weeks. Tell us the app and what you need from its data at /contact.html; access and compliance are arranged with you.

Mapping last checked 2026-05-16.