Account data inside AEB Mobile, and how we reach it

Open AEB Mobile and the first screen is a list of accounts in more than one currency, each carrying its own balance, cards and movement history — Armeconombank's listing calls it "your digital bank." That is the shape of the data an integrator usually wants out of it: a multi-currency ledger, a set of cards on Visa, Mastercard and the local ArCa network, and a running feed of transfers, utility payments, deposits and loan repayments. None of it leaves the bank on its own. The work here is to stand up an authorized client that signs in the way the app does, pulls the full history once, then keeps it current.

What it holds behind the login

The app's own feature list, plus Armeconombank's product pages, name the surfaces below. Granularity is what a consenting account would expose to a clean client; exact field names are settled during the build, not published by the bank.

Three ways into the data

User-consented protocol integration

With a consenting account holder — or your own corporate AEB login — we capture how the app authenticates and reads, then implement the session and data calls as a maintained client. Reachable: everything the app itself shows. Effort is moderate; durability tracks the app's release cadence, and we re-validate when a build changes. Access is arranged with you during onboarding, against a consenting account.

Statement and record export

AEB produces statements, and the app surfaces records a user can pull down. Where a live session is not wanted, we parse those files into the same schema as a lighter, very stable feed. It is historical rather than real-time, which suits reporting more than monitoring.

Consented open finance, when it lands

The Central Bank of Armenia is still assembling its open-banking and open-finance rules and joined the Global Financial Innovation Network in 2025. There is no mandated AIS feed to call today. We design the schema so that, the day a consented standard goes live, the same normalized records re-point at it with little rework.

For AEB the protocol route is the one we would build on. The export feed is a sensible backstop for reporting, and the consent route is where the integration moves the moment Armenia's framework is in force. We would say so plainly in the hand-off notes and leave the switch easy.

A backfill call, sketched

AEB ties a session to a registered device and gates it behind Face ID or fingerprint. A headless client registers a build device once, refreshes that device-bound token, then walks transactions by cursor — bulk on the first run, deltas after. The shape below is illustrative; the real paths and fields are confirmed during the build.

# Illustrative only — paths/fields confirmed on the build, not published by AEB.

POST /session/refresh
  device_id : <registered-device-uuid>
  refresh   : <stored-refresh-token>
-> 200 { access: <jwt>, expires_in: 600 }

GET /accounts
  Authorization: Bearer <jwt>
-> [ { account_id, currency: "AMD", iban, balance, card_ids: [...] }, ... ]

# First run = bulk backfill; later runs pass the saved cursor for a delta:
GET /accounts/{account_id}/transactions?cursor=<last>&limit=200
  Authorization: Bearer <jwt>
-> { items: [ { tx_id, posted_at, amount, currency, fee,
                counterparty, channel: "easy_transfer|utility|fx|remittance",
                status } ],
     next_cursor: <opaque> }
# A 401 on the data call triggers one /session/refresh and a single retry.
      

How an AEB record lands in your store

Raw responses get normalized before they reach your database, so a parking fine, a fee-free Easy transfer and a foreign-currency credit all share one typed shape. The principal, the fee and the FX rate stay in separate fields — never collapsed into a single number.

{
  "source": "aeb.armeconombank",
  "account": { "id": "...", "currency": "AMD", "iban": "AM..", "type": "current" },
  "txn": {
    "id": "...",
    "posted_at": "2026-06-14T08:41:00+04:00",
    "principal": { "amount": -15000, "currency": "AMD" },
    "fee":       { "amount": 0,      "currency": "AMD" },
    "fx":        { "rate": null, "from": null, "to": null },
    "channel": "easy_transfer",
    "counterparty": { "handle": "+374********", "name": null },
    "status": "posted"
  }
}
      

What ships to you

The headline deliverable is code you run, not a report you read:

• Runnable client source in Python and Node.js for AEB's session, accounts, cards, transactions, deposits and loan-repayment surfaces.
• A backfill-and-sync runner: bulk first load, then cursor-based delta pulls, with idempotent writes so a re-run reconciles rather than duplicates.
• An automated test suite run against recorded AEB responses, so a renamed or moved field shows up as a failing assertion instead of quietly corrupting a sync.
• The normalized schema and mapping that turns accounts, cards, transactions, FX, deposits and loans into the typed records above.

Alongside the code you get an OpenAPI description and an auth-flow write-up of the device-registration, biometric-gated session and token-refresh chain, interface documentation for each surface, and short notes on consent capture and data retention. Those round out the package; the client and the sync runner are what you wire in.

Consent, banking secrecy and the CBA's timeline

Armenia has not put an open-banking mandate into force, so this integration does not ride a regulated scheme. It rests on the account holder's authorization. Personal data is governed by the Law on Protection of Personal Data, enforced by the Personal Data Protection Agency under the Ministry of Justice, and account detail additionally falls under banking-secrecy rules — which is exactly why consent and the route both matter. We capture and log the user's consent, record what was accessed and when, keep the data set to what the project needs, and work under an NDA where the engagement calls for one. If and when the CBA moves open finance from guidance to a consented standard, that becomes a cleaner route, and the schema is already built to take it.

Build details we account for

Device-bound, biometric-gated sessions. AEB registers a device and opens the session behind Face ID or fingerprint, so a sync cannot just replay a password. We register a build device during onboarding and own the token-refresh path, so the client holds a live session without a person re-authenticating on every pull.

Genuinely multi-currency accounts. A single customer can hold AMD, USD and EUR balances at once, with FX running inside the app. We model each account and currency as its own stream and keep the applied rate on every converted record, instead of forcing one base currency at ingest and losing the real cost.

Many record shapes under one feed. Utility, tax, parking and condominium payments, loan repayments, fee-free Easy transfers and inbound My Transfer remittances all post as different shapes. We map each to a typed channel during the build, so a deposit replenishment and a parking fine never land in the same undifferentiated bucket.

Screens we mapped

Listing screenshots we worked from while sketching the surfaces above. Select to enlarge.

Other Armenian banking apps in the same picture

If you are aggregating accounts across Armenia rather than a single bank, AEB usually sits next to these. Named here for context only — each holds account, card and transaction data of the same broad kind, which is what makes a unified feed worthwhile.

• ACBA Digital — Acba Bank's app, a heavy retail user base with cards, transfers and bill payments.
• MyAmeria — Ameriabank's banking app, accounts, deposits and FX across currencies.
• Idram & IDBank — combines an e-wallet with IDBank accounts, popular for everyday payments.
• InecoOnline / InecoMobile — Inecobank, known for opening cards quickly in-app.
• Ardshinbank mobile banking — round-the-clock account operations and card management.
• Converse Mobile — Converse Bank's app for accounts, transfers and payments.
• Evocabank — a digital-first Armenian bank with a mobile-led account experience.
• Fast Bank — newer entrant with online account onboarding and card issuance.

Questions integrators ask about AEB

Does AEB run on Armenia's ArCa switch, and does that affect what we can read?

AEB issues Visa, Mastercard and ArCa cards, and ArCa is the national processing switch most local card and account activity passes through. We read card and transaction records at the app's own session layer, so a record reaches you the same way whether the underlying rail is ArCa, Visa or Mastercard. The card scheme shows up as a field, not as a separate integration.

Once you've backfilled my AEB history, how do you keep it current without re-pulling everything?

The first load is a bulk backfill of accounts, cards and transactions. After that we sync deltas: each pull carries a cursor or a last-seen transaction marker, so a refresh fetches only what posted since the previous run instead of the whole ledger. Multi-currency accounts are tracked per account, so a new AMD or USD movement is picked up on its own line.

Armenia hasn't mandated open banking yet — what legal basis does the integration rely on?

The dependable basis is the account holder's own authorization. The Central Bank of Armenia is still building its open-banking and open-finance framework, so we don't lean on a mandated scheme. We operate under the user's consent, the Law on Protection of Personal Data and banking-secrecy rules, with consent and access logged and data kept to what the project needs.

Can you separate fees and FX from the raw transfer amount in AEB's records?

Yes. Easy transfers between AEB accounts are fee-free, while cross-border transfers, utility payments and currency exchange each carry their own amount, fee and rate. We map those into separate normalized fields, so your ledger sees the principal, the fee and the applied exchange rate as distinct values rather than one lumped figure.

Starting an AEB build

Send us the app name and what you need out of it, and we scope the surfaces from there — most AEB builds run a one-to-two-week cycle. One way to engage is source-code delivery: you get the runnable client, the sync runner, tests and docs for a flat fee from $300, paid after delivery once it works the way you need. The other is our hosted API — you call our endpoints for AEB data and pay per call, with nothing up front and no build to maintain on your side. Either way, access and consent are arranged together with you during onboarding. Tell us which fits at /contact.html and we will come back with a concrete plan.

Sources and review

Worked from Armeconombank's own mobile-banking and product pages, the app's store listing, and the Central Bank of Armenia plus open-banking trackers for the regulatory state, in June 2026. Primary references:

• AEB Mobile — Armeconombank (aeb.am)
• AEB Mobile on Google Play (com.banqr.aeb)
• Armenia open-banking regulation status
• Central Bank of Armenia — payment systems

OpenFinance Lab · interface review, 2026-06-15.