How myABL’s account, RAAST and card data gets integrated

myABL’s package id, com.ofss.digx.mobile.android.allied, places it on Oracle Banking Digital Experience — the OFSS digx stack that fronts FLEXCUBE. That single fact decides most of the integration. Per Oracle’s own OBDX host-integration documentation, the platform exposes a customer’s banking world as REST web services that decouple the presentation layer from the service layer. So the app you see is a client of a typed API surface, not a screen-scrape target. The work is mapping that surface for one consenting Allied Bank customer and handing back clients you can run.

Allied Bank describes myABL as serving millions of users across Pakistan, with money transfer over IBAN, account number, CNIC and RAAST, bill and franchise payments, card controls, advance-salary lending and an ABL Asset Management investment view. The data worth integrating sits behind login: balances, statements, the transaction ledger, RAAST identity, and the loyalty (myABL Coins) records. Below is where each lives and the route we run to reach it.

What myABL holds, and where it comes from

Mapped from the app’s own feature list and the OBDX resource model. Granularity reflects what the authenticated session returns, not what a public page shows.

The routes that genuinely apply

Authorized protocol analysis of the OBDX session

The dependable path. With a consenting Allied Bank account, we capture the live digx request chain the app drives — login and token issuance, the demand-deposit fetch, the statement and transaction calls, the RAAST and card resources — and rebuild it as a typed client. Effort is moderate because OBDX is a known, well-shaped REST platform rather than a bespoke backend; the main work is enumerating the exact resource paths, headers and entitlement checks Allied Bank has switched on. Durability is good between front-end releases; we account for the cases where it isn’t in the engineering notes.

RAAST and the SBP open-banking direction

The State Bank of Pakistan published an open-banking framework emphasising standardised APIs for customer-permitted data sharing, and RAAST was built with open-API connectivity and a directory function. Where a programme participant route is available for a given flow — proxy resolution, payment initiation — we use it, because a regulated rail beats a reverse-engineered one for anything that moves money. Coverage today is narrower than the in-app surface, so this complements rather than replaces the first route.

Native export as a fallback

myABL lets a user download statements and tax/maintenance certificates as files. For a one-off or low-frequency need, parsing those artifacts is the lightest option and avoids any session work. It does not scale to real-time balances, which is why it sits underneath the live-session route.

For most callers we build on the OBDX session route and bolt RAAST onto the payment-initiation flows where it qualifies; native export stays as a cheap escape hatch for document-only jobs. Which mix is right depends on whether you need live balances or just periodic ledgers — tell us the cadence and we size it.

What lands at the end

Each item is tied to a real myABL surface, not a generic checklist.

• An OpenAPI/Swagger spec covering the accounts, statement, transaction, RAAST and card resources as Allied Bank exposes them.
• A protocol and auth-flow report: the OBDX login, token issuance and session/cookie chain, plus how 401s and token refresh behave in practice.
• Runnable source — Python or Node.js — for the key calls: balance read, statement/transaction pull, RAAST ID lookup, card state.
• Normalised output schemas so a PKR transaction line, a RAAST alias and a card record come out in stable shapes.
• Automated tests against a consenting account or sandbox, and interface documentation an in-house team can maintain.
• Compliance and data-retention guidance written for the SBP context, including data-localisation handling.

The call chain, sketched

Illustrative shape of the OBDX session for a consenting myABL account. Exact paths, headers and entitlement gates are confirmed during the build against the live front end — OBDX deployments vary by what each bank switches on.

# 1. Authenticate -> OBDX issues a session token
POST /digx/v1/login
  Headers: Content-Type: application/json, X-Token-Type: JWT
  Body:    { "username": "<consented>", "determinationType": "PASSWORD" }
  => 201  Authorization: Bearer <jwt>   (+ session cookie)

# 2. List demand-deposit accounts for that customer
GET /digx/v1/accounts/demandDeposit?status=ACTIVE
  Headers: Authorization: Bearer <jwt>, X-Target-Unit: ABPK
  => 200  { "accounts": [
       { "id": { "value": "PK..IBAN.." },
         "currentBalance": { "amount": 0.00, "currency": "PKR" } } ] }

# 3. Pull the transaction ledger behind a statement
GET /digx/v1/accounts/demandDeposit/{accountId}/transactions?fromDate=..&toDate=..
  => 200  { "transactions": [
       { "valueDate":"..", "amount":{"amount":..,"currency":"PKR"},
         "type":"DEBIT", "narration":".." } ] }

# Error handling: a 401 means the token aged out -> re-run step 1,
# replay the in-flight request once, then surface a hard failure.
      

Consent and the Pakistani rulebook

The State Bank of Pakistan is the prudential authority here, and RAAST is its instant-payment rail. There is no consumer-facing AIS licensing regime in Pakistan equivalent to the UK’s; the dependable legal basis for this work is the account holder’s own authorization to access their data, recorded and scoped. The Payment Systems and Electronic Fund Transfers Act 2007 governs confidentiality of transaction data, and the SBP’s technology-governance expectations apply to how customer data is obtained and transmitted. The Personal Data Protection Bill remains a draft pending enactment, so we treat its consent and data-minimisation principles as the operating standard rather than citing it as settled law.

One concrete constraint we design around: Pakistan’s draft regime expects critical personal data to be processed on infrastructure inside the country. We keep consent records and access logs, minimise the fields a given integration actually reads, and put an NDA in place where the engagement needs one.

Engineering notes we account for

OBDX exposes a determination type on login and lets each bank configure step-up and biometric flows; we map how Allied Bank has set this so a token earned at one assurance level isn’t assumed to entitle higher-risk resources like RAAST transfers. We scope read-only and payment-initiation entitlements separately for exactly this reason.

The transaction resource paginates and windows by date, and statement PDFs are rendered server-side — so we design the sync to page through history and reconcile structured lines against the PDF total rather than trusting either alone. When Allied Bank ships a front-end update, OBDX resource paths usually hold but headers and entitlement gates can shift; we build a re-validation pass into maintenance so a quiet change surfaces as a failing test, not as silent data drift. Access to a consenting account or a sandbox is arranged with you during onboarding — it’s our step in the project, not a hoop to clear first.

Interface evidence

Store screenshots of the live myABL interface, used to anchor the surfaces above. Tap to enlarge.

How this was checked

I read the myABL Play Store and Allied Bank listings for the feature set, cross-referenced the com.ofss.digx package against Oracle’s Banking Digital Experience host-integration docs to confirm the platform and its REST model, and reviewed the State Bank of Pakistan’s RAAST material and Pakistan’s data-protection draft for the regulatory frame. Checked 27 June 2026.

• myABL on Google Play
• Oracle Banking Digital Experience — Host Integration introduction
• State Bank of Pakistan — RAAST
• Pakistan data-protection overview (ICLG 2025–26)

Mapped by the OpenBanking Studio integration desk · June 2026.

Comparable apps in the same data ecosystem

Other Pakistani banking and wallet apps a unified integration commonly sits alongside. Named for context, not ranked.

• HBL Mobile — Habib Bank’s app; balances, transfers, bill pay and account opening behind login.
• UBL Digital — United Bank’s retail app; accounts, cards and payments.
• Alfa — Bank Alfalah’s app, covering accounts, transfers and lifestyle payments.
• Meezan Bank — Pakistan’s largest Islamic bank; account and transaction data under an Islamic-finance model.
• SC Mobile Pakistan — Standard Chartered’s local app; balances, cards and transfers.
• JazzCash — mobile wallet with balances, transfers and a billing ledger, often without a traditional bank account.
• Easypaisa — wallet and branchless-banking platform with payment and savings records.
• SadaPay — modern digital-banking app with a card-linked spend feed.
• NayaPay — social-payments app with free transfers and a card-linked account.

Questions an integrator actually asks

myABL is built on Oracle OBDX — does that shape the integration?

It helps. The com.ofss.digx package puts myABL on Oracle Banking Digital Experience, whose data layer is a set of REST web services behind token auth. We map the live /digx call chain the app uses, then build typed clients against the accounts, transactions and payments resources rather than scraping rendered screens.

Does RAAST data move through the same channel as balances and statements?

In myABL it surfaces through the same authenticated session, but the RAAST ID lifecycle (create, link, delink, delete) and RAAST transfers are distinct resources from the demand-deposit and statement endpoints. We model them separately so a consumer can pull balances without being entitled to move funds.

Allied Bank is a Pakistani institution — which rules govern the data?

The State Bank of Pakistan is the prudential regulator; RAAST and the SBP open-banking direction set the rail-level standards, and the Payment Systems and Electronic Fund Transfers Act 2007 plus the pending Personal Data Protection Bill frame customer-data handling. Critical personal data is expected to stay on infrastructure inside Pakistan, which we design the deployment around.

Can statements come out structured, or only as the PDF the app downloads?

Both. The PDF and mini-statement are the native artifacts a user sees, but the transaction history behind them is returned as structured records by the OBDX transaction resource. We normalise those into JSON or CSV with stable date, amount, currency and counterparty fields.

Working with us

You give us the app name — myABL — and what you need out of it; we handle the access, the OBDX mapping and the compliance scaffolding. Delivery runs in a 1–2 week cycle. Take the source-code package from $300 — runnable clients plus the spec, tests and docs, paid only after delivery once you’re satisfied — or call our hosted endpoints and pay per call with no upfront fee. Start the conversation at /contact.html.