Pulling cards, statements and transfers out of ForteApp

ForteBank JSC has run a retail bank in Kazakhstan for more than two decades, and ForteApp is now where its customers keep cards, deposits, loans and a running transaction ledger — reported at over 950,000 monthly active users in coverage of the bank. For a team that wants that data inside its own systems, the practical question is not where it lives but how to read it on a schedule: a client that signs in, pulls the statement feed, and keeps a normalized copy current. That ingestion path is what this page is about. We hand you a runnable client and the sync around it, written against ForteApp's real surfaces, not a generic stub.

What ForteApp holds per customer

Each row below is a surface a signed-in user already sees in the app. The mapping is what an integrator does with it once it is structured.

Ways in, and the one we would pick

Three routes genuinely apply to ForteApp. They differ in coverage, maintenance and how durable they are as Forte ships changes.

Consented open-banking read

Kazakhstan operates a consent-based exchange under the Open API and Open Banking Concept for 2023–2025. The National Payment Corporation runs the information-exchange system; the pilot scenario was current-account information, with second-tier banks onboarding in stages. Reach today is the account-information subset the scheme exposes; durability is high because it is regulator-backed and consent-recorded. We set up the consent flow with you. Honest gap: the pilot's first named participants were other banks, and product-level APIs are still rolling out, so this channel alone will not cover deposits, loans or loyalty yet.

Authorized protocol analysis of the app

Reading ForteApp's own traffic under the customer's authorization reaches everything the logged-in user sees, at app fidelity — cards, FX, deposits, loans, the loyalty ledger. Effort is higher and it tracks the app version, so maintenance includes a periodic check that the mapping still holds. This is the route that covers the full domain list above today.

User-consented credential access and native export

For a one-off or low-volume pull, a consenting account session plus the app's own statement export is enough to seed a backfill. It is the lightest option and a fine fallback; it does not give you a live feed on its own.

For most teams we run the protocol route as the working backbone now and bring the open-banking channel in for the account-information slice as it widens — you get full coverage immediately and a more durable basis over time. We say which parts ride which route in the spec.

What lands in your repo

The headline deliverable is code you can run, not paperwork. In order of what you touch first:

• A runnable client (Python and Node.js) wrapping device-bound login, token refresh and the calls behind cards, accounts, statements, transfers, deposits and FX — returning typed objects.
• An ingestion runner — cursor-based incremental sync plus a first-run statement backfill, with upserts keyed on the transaction id.
• An automated test suite running against recorded fixtures, covering the mapped fields and the auth handshake so version drift turns up in the suite.
• A normalized schema mapping Forte's fields to a ledger model that keeps currency and transfer rail as first-class columns.
• An OpenAPI/Swagger description of the mapped surface, a short auth-flow report covering the token chain, interface documentation, and data-retention and consent-logging notes — the reference layer, delivered alongside the code.

A client against the statement feed

Illustrative shape of the delivered Python client, confirmed against the live surfaces during the build:

from forte_client import ForteSession   # the client we ship

# login + token refresh handled inside the session;
# re-consent is scheduled within the authorization window
s = ForteSession.from_consent(consent_ref)

# incremental pull for one account, paged by cursor
cursor = store.last_cursor(account_id)
for page in s.statements(account=account_id, since="2026-05-01", cursor=cursor):
    for tx in page.transactions:
        ledger.upsert(
            key=tx.id,                  # re-pulled rows update in place
            posted=tx.booked_at,
            amount=tx.amount,
            ccy=tx.currency,            # KZT / USD / EUR
            counterparty=tx.counterparty,
            rail=tx.rail,               # p2p | card | swift | zolotaya_korona | quickpay
        )
    store.save_cursor(account_id, page.next_cursor)

Field names and the auth handshake are pinned during the build and written into the auth-flow report, so what you read here matches what runs.

Consent and the Kazakhstan open-banking regime

The governing framework is the Concept for the Development of Open API and Open Banking for 2023–2025, approved in December 2022 at the National Bank of Kazakhstan's initiative, with the Agency for Regulation and Development of the Financial Market and the Agency for Protection and Development of Competition. Its stated aim is standardized financial-data exchange strictly with the client's consent. The National Payment Corporation built and operates the exchange; the first live scenario was customer current-account information. Personal data is handled under Kazakhstan's data-protection law, which the scheme's designers have flagged as the pacing item for wider rollout.

How we operate sits inside that: access is authorized and documented, every consent and pull is logged, the data set is minimized to what your use case needs, and we sign an NDA where the work touches anything sensitive. Consent is recorded with an expiry and is revocable, and the sync respects both.

What we plan around on this build

Two things on ForteApp need deliberate handling, and we account for them rather than leaving them for you.

Multi-currency without double counting. Balances and transactions span tenge, dollars and euros, and the app's FX screen executes conversions. We carry currency through every row and reconcile an executed conversion as its own event, so a USD-to-KZT exchange is not booked as if it were an outbound transfer.

Heterogeneous transfer rails. A transfer can move by phone number, account, card, SWIFT, Zolotaya Korona or Alem, and they settle and reverse differently. We tag each row with its rail so cross-border SWIFT activity and domestic instant transfers reconcile on their own terms instead of being lumped together.

Access itself — a consenting account, a test profile, or a sponsor sandbox — is arranged with you during onboarding; it is part of how the project runs, not something you have to produce up front.

Where teams put this data to work

• A lender reading a consenting applicant's Forte statement and balances for an affordability check.
• An accounting tool syncing a business owner's Forte transactions into the books each night.
• A personal-finance app aggregating Forte balances next to other Kazakhstan banks for one view.
• A treasury dashboard logging FX conversions and multi-currency balances as they happen.

Screens we worked from

Public ForteApp store screenshots, used to map the surfaces above. Tap to enlarge.

Other Kazakhstan banking apps in the same picture

A unified integration usually spans several of these. Each holds the same kind of per-customer record, so the same ingestion model tends to carry across them.

• Kaspi.kz — the country's largest super-app, blending bank accounts, payments and a marketplace ledger.
• Halyk (Homebank) — Halyk Bank's app, covering accounts, cards, transfers and deposits at national scale.
• Home.kz — Home Credit Bank's app, with loans, deposits and inter-bank transfers; one of the open-banking pilot banks.
• Jusan — accounts, cards and payments alongside lifestyle services.
• BCC.kz — Bank CenterCredit's app, a named participant in the account-information pilot.
• Bank RBK — multi-currency accounts and cards, also among the pilot's second-tier banks.
• Altyn Bank — retail accounts and transfers; part of the early open-banking scenario.
• Freedom Bank — a digital-first bank inside a broader financial ecosystem.

Questions integrators ask about ForteApp

Which ForteApp surfaces can a Python or Node client actually reach?

Everything a signed-in customer sees on a phone: card list and limits, account balances, the transaction and statement history, transfers across the rails Forte offers, deposits and loan schedules, the FX screen, and the loyalty ledger. The delivered client wraps the login and token refresh and exposes those as ordinary method calls returning typed objects, so you are not parsing screens by hand.

How does the consented route relate to Kazakhstan's open-banking pilot?

Kazakhstan runs a consent-based scheme under the Open API and Open Banking Concept for 2023 to 2025, operated through the National Payment Corporation's information-exchange system. The pilot started with current-account information for a set of second-tier banks. Where that channel covers what you need for a consenting customer, we use it; for the surfaces it does not reach yet, we read the app at customer authorization instead, and fold the scheme in as it widens.

How do you keep a long-running Forte sync current without manual re-linking?

The client tracks the authorization's validity window and schedules re-consent inside it, so an unattended sync keeps its mandate. Incremental pulls use a per-account cursor and key on the transaction id, so a re-pulled page lands as an update rather than a duplicate row.

Does the multi-currency and transfer-rail mix complicate the data model?

It is the part worth getting right. Balances and movements span tenge, US dollars and euros, and transfers arrive by phone number, account, card, SWIFT, Zolotaya Korona and Alem. We carry currency and rail through the schema rather than flattening them, and reconcile an FX conversion separately so it is not mistaken for an outbound transfer.

How is access to a Forte account arranged for the build?

You give us the app name and what you want out of its data; the consent, a test account or a sponsor sandbox are arranged together with you during onboarding. Access setup is part of the engagement, not a checklist you clear before we start.

Getting a build started

A first working client usually lands within one to two weeks of access being sorted out with you. Source-code delivery starts at $300: you receive the runnable Python and Node client, the ingestion runner, the test suite and docs, and you pay once it is in your hands and you are satisfied with it. To skip hosting entirely, take it as hosted endpoints instead and pay per call, with nothing upfront. Tell us the app and what you need from its data, and we will scope it — start a conversation here.

Sources and what we checked

Surfaces were mapped from ForteApp's public store listing and screenshots; the regulatory picture from Kazakhstan's open-banking primary sources, checked in June 2026. Engineering notes by OpenFinance Lab, last checked 2026-06-07. Key references:

• ForteApp – online bank on Google Play (kz.forte.bank)
• National Bank of Kazakhstan — Open API, Open Banking
• National Payment Corporation — Open Banking System
• The Astana Times — What stands behind Kazakhstan's open-banking initiative (Apr 2025)