Account, card and deposit data inside AEB Mobile

Armeconombank ships AEB Mobile on the Banqr platform — the Play listing carries the package id com.banqr.aeb, and Apple lists the same app under id 1518392966. Behind a biometric unlock it runs almost the whole branch: multi-currency accounts, Visa and Mastercard inventory, deposits, loans, currency exchange, and two transfer rails — domestic and cross-border out of Armenia, plus My Transfer crediting a card from abroad. That spread of authenticated, per-user state is the reason a fintech, an accounting product, or a treasury tool would want a programmatic read of it.

No vendor conversation is needed for that read. The bank sits in Armenia, where a mandatory data-access regime is not yet live, so the working basis is the account holder's authorization and a careful map of the app's own request traffic. The data is real and structured; the route is the part we engineer.

What the app actually holds

The rows below come from the published feature set on the Play listing and aeb.am, mapped to where each surface originates and what an integrator does with it.

Getting to the data

Three routes apply to this app. They are not equal, and the recommendation is plain: for AEB Mobile we build on authorized protocol analysis of the app's own client traffic, run against a consenting account, because that reaches every read surface above today and does not wait on a scheme that Armenia has not yet switched on.

1 — Authorized protocol analysis (the one we run)

We observe how the installed app authenticates and requests data, then re-implement those calls as a documented client. Reaches accounts, cards, transfers, deposits, loans and payment history. Effort is moderate; durability depends on the app's release cadence, which we account for with a re-check step. Access is arranged with you during onboarding against a consenting account or a test profile — that setup is our job, not a gate you clear first.

2 — User-consented credential access

Where an account holder authorizes it, a consent-scoped session drives the same flows for that user. Good fit for products that onboard their own users and want per-user pulls. We handle the consent capture, scoping and revocation handling.

3 — Native export as a backstop

Statement and history exports the app already produces serve as a reconciliation feed and a low-frequency fallback when a richer pull is paused for re-validation. Narrower and slower, but useful as a cross-check.

A regulated AIS route is not yet a live option here; if the Central Bank of Armenia stands up a formal scheme, we re-point route 1's auth onto it without disturbing the schema you already consume.

Where this gets used

• A Yerevan accounting SaaS pulls a customer's AEB statements nightly and categorises utility and FX lines automatically.
• A personal-finance app aggregates AMD, USD and EUR balances from AEB alongside other Armenian banks into one net-worth view.
• An SME treasury tool watches transfer-out and My Transfer-inbound activity to reconcile receivables same-day.
• A lender ingests deposit and loan positions, with the customer's consent, to pre-fill an application.

What lands in your repo

Each item is built against the surfaces above, not a generic template:

• An OpenAPI description of the mapped endpoints — accounts, cards, transfer history, deposits, loans — with the multi-currency model made explicit.
• A protocol and auth-flow report covering the token issue/refresh chain behind the biometric unlock and how sessions are held.
• Runnable source for the key reads in Python and Node.js, with retry and error handling.
• A normalized transaction schema so AEB rows line up with other banks you ingest.
• Automated tests against recorded responses, plus interface documentation.
• Data-retention and consent-handling guidance written for Armenian personal-data rules.

A sample of the shape

Illustrative only — exact field names and the auth handshake are confirmed during the build against a consenting account.

# Authorize once, then read the multi-currency account set
POST /mobile/v1/auth/session
  { "device_id": "...", "credential": "<consented>" }
-> 200 { "access_token": "...", "refresh_token": "...", "expires_in": 600 }

GET /mobile/v1/accounts        Authorization: Bearer <access_token>
-> 200 {
     "accounts": [
       { "id": "ACC-AMD-01", "currency": "AMD", "balance": 482350.00, "type": "current" },
       { "id": "ACC-USD-07", "currency": "USD", "balance": 1290.55, "type": "current" }
     ]
   }

# Statements are pulled per account+currency, never netted across them
GET /mobile/v1/accounts/ACC-USD-07/statement?from=2026-05-01&to=2026-05-31
-> 200 { "items": [ { "ts": "...", "amount": -45.00, "channel": "utility", "counterparty": "..." } ] }

# 401 -> refresh, do not re-prompt the user mid-session

Consent and the rulebook

Oversight sits with the Central Bank of Armenia. The CBA has moved toward open banking — it joined the Global Financial Innovation Network in 2025 and is discussing a PSD2-style localisation — but a mandatory third-party access regime is not yet in force, so we do not lean the integration on a rule that has not arrived. The dependable basis is the account holder's own authorization. Personal data is handled under the Republic of Armenia's Law on the Protection of Personal Data, and AEB publishes its own privacy terms. We work to a consent scope that names the data domains, honours revocation, logs every access, minimises what is stored, and sits under an NDA where the engagement needs one.

Engineering notes we plan around

Two things about AEB specifically shape the build:

• Multi-currency by default. A single customer routinely holds AMD plus one or more foreign-currency accounts, and the My Transfer rail credits a card directly. We model balances and movements per account-and-currency so nothing gets silently summed across currencies, and FX-exchange lines keep their rate.
• The biometric unlock is a local gate, not the auth. Face ID and fingerprint unlock the app locally; the real session is a server token with a short life. We map the actual issue-and-refresh chain and design the sync around its expiry so a long pull does not drop mid-run.
• Card tokens are device-bound. Google Pay and AEB Pay NFC provisioning belongs to the handset, so we read card lifecycle state — apply, reissue, block, status — rather than treating the wallet token as a queryable surface.
• Front-end churn. Banqr ships app updates, so we keep a re-check pass in maintenance that flags a changed response shape before it reaches your pipeline.

Interface evidence

Public store screenshots, opened to full size — useful for confirming which surfaces are in scope.

Peer apps in the same data space

Integrators rarely want one Armenian bank in isolation; these neighbours come up when a single normalized feed is the goal.

• ACBA Digital — ACBA Bank's app; accounts, cards and payments, among the most used in Armenia.
• MyAmeria — Ameriabank's app, with deep utility-payment and template features.
• Idram & IDBank — pairs the Idram wallet with IDBank accounts in one ecosystem.
• Ardshinbank Mobile — accounts, cards and the main utility billers.
• Converse Bank Mobile — retail accounts and recurring payments.
• Inecobank (InecoOnline) — accounts, transfers and card management.
• Telcell Wallet — a widely used payment wallet holding balances and transaction history.
• Idram — Armenia's large standalone wallet, accepted across thousands of merchants.

How this was checked

Reviewed June 2026 against the app's own store and bank pages and Armenia's open-banking status. Sources opened: AEB Mobile on Google Play, Armeconombank's AEB Mobile page, Open Banking Tracker — Armenia, and AEB's privacy terms. Compiled by the OpenBanking Studio integration desk, June 2026.

Questions integrators ask about AEB

AEB Mobile mixes AMD and foreign-currency accounts — how is that reflected in the data you return?

Each account is returned with its own currency code and balances are never collapsed into a single figure. A customer can hold AMD, USD, EUR and other currency accounts in parallel, and the My Transfer inbound rail credits a card directly, so the normalized schema keys every balance and movement to its account and currency rather than netting them.

Does Armenia have an open-banking scheme we can connect through for Armeconombank?

The Central Bank of Armenia has signalled a move toward open banking — it joined the Global Financial Innovation Network in 2025 and is discussing a PSD2-style localisation — but no mandatory access regime is in force yet. So the dependable basis is the account holder's own authorization, with the integration built through protocol analysis of the app's own traffic.

Card tokens, Easy transfer and utility payments all live in AEB Mobile — which surfaces can you actually map?

The read surfaces are the durable ones: account balances and statements, card inventory and status, deposit and loan positions, and transfer and payment history including Easy transfer and utility records. Device-bound card tokenization for Google Pay and AEB Pay is mapped as lifecycle state, not re-implemented as a wallet.

One way to run this ends in runnable source you own: we map AEB's surfaces and hand back the code, the OpenAPI spec, tests and documentation, from $300, paid only after delivery once you are satisfied. The other skips the build entirely — 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, and access and compliance get arranged with you — start at /contact.html.