Reaching Erste account data after the Santander Bank Polska rebrand

The package on Google Play still reads pl.bzwbk.bzwbk24 — Bank Zachodni WBK, then Santander Bank Polska, and since the late-April 2026 rebrand reported across the Polish financial press, Erste Bank Polska. The app itself states it was previously called Santander mobile. For an integrator, the name on the icon is the least interesting thing about it: behind one login sit retail current accounts, instant transfers and standing orders, BLIK, cards, insurance policies, and an in-app aggregation surface the bank calls Erste Open. That is a regulated payment account in Poland, so the cleanest path to the core of it is the one the law already defines.

The route into the data

Three approaches genuinely apply here, and they are not equal.

Regulated account information over PolishAPI

Poland runs PSD2 through a domestic interface standard, PolishAPI, maintained by the Polish Bank Association. Its AIS scope returns account details, balances, and posted and pending transactions; the same standard also covers confirmation of funds. Authorization is OAuth2-based with a PolishAPI scope_details extension, and strong customer authentication runs through an External Authorization Tool — decoupled, or via an exchange or refresh token. Reachable through this channel: the spine of the account — money in, money out, who and when. It is the durable choice because the bank must keep it working under supervision. We handle the third-party onboarding, the eIDAS QWAC and QSEAL certificates and the sandbox registration with you as part of the build, not as homework handed back to you.

Authorized interface integration of the app's own traffic

A lot of what makes this app useful never travels over the regulated channel. BLIK code events, the Subscriptions view, Price advisor progress toward a zero-fee Smart Account, Financial Coach spend and income charts, insurance policy numbers and coverage periods, in-app parking, motorway and transit-ticket purchases — those are app-derived. We map the authenticated request and response flow, including the mobile-authorisation token and PIN/biometric chain, under the client's authorization against a consenting account. Effort is higher and the surface moves when the app updates, which we plan for rather than discover.

Native export, as a backstop

Where neither of the above fits a given field, statement exports from web banking — PDF or structured formats — are parsed into the same normalized schema so a downstream consumer sees one shape. This is a fallback for coverage gaps, not the spine.

For most teams the sensible build is the regulated PolishAPI feed for everything an account statement would contain, with a thin authorized-interface layer added on top for the BLIK, PFM and insurance fields the regulated scope was never meant to carry. We say which fields fall on which side before any code is written, so there are no surprises about where a value comes from.

What it holds, and what you would do with it

The build you receive

Delivery is the working integration, not a feasibility memo. Concretely, for this app:

• An OpenAPI specification covering the account, balance, transaction and standing-order surfaces, plus the BLIK and insurance fields drawn from the authorized-interface layer.
• A protocol and auth-flow report — the PolishAPI OAuth2 scope_details grant and External Authorization Tool flow for the regulated feed, and the mobile-authorisation token, PIN and biometric chain for the app surfaces.
• Runnable source for the key endpoints in Python and Node.js: consent setup, transaction pull with pagination, balance read, and the app-derived calls.
• An automated test suite covering token refresh, the consent-refresh window, pagination edges and the empty-history case.
• Interface documentation, a normalized schema so Erste data matches other Polish banks in the same pipeline, and data-retention and consent-logging guidance.

A worked example: pulling cleared transactions

Shape follows the PolishAPI v2.1 AIS specification; header and field values are illustrative and are confirmed against the live sandbox during the build.

POST /v2_1.1/accounts/getTransactionsDone HTTP/1.1
Host: psd2.{aspsp-host}
Authorization: Bearer <ais_access_token>        # OAuth2, scope: ais
X-JWS-SIGNATURE: <detached-jws-of-body>
Content-Type: application/json

{
  "requestHeader": { "requestId": "8f2c-...", "userAgent": "obstudio/1.0",
                      "ipAddress": "—", "sendDate": "2026-05-17T09:14:00Z" },
  "accountNumber": "PL00 1090 ... 0001",
  "transactionDateFrom": "2026-04-01",
  "transactionDateTo":   "2026-05-17",
  "pageId": null,                                   # cursor; echoed back when more pages
  "perPage": 200
}

# 200 OK -> { "transactions": [ { "itemId", "amount": {"value","currency":"PLN"},
#   "tradeDate", "bookingDate", "transactionType", "counterparty": {...},
#   "description", "transactionCategory" } ... ], "nextPage": "" }
#
# 401 -> consent or token expired: re-run the EAT/SCA step, do not silently retry.

Consent and the KNF rulebook

The operative regime is PSD2 as transposed into Polish law through the Ustawa o usługach płatniczych, supervised by the Komisja Nadzoru Finansowego. A provider offering only account information registers in the KNF register of payment service providers rather than seeking full authorization; the technical contract with the bank is the PolishAPI standard. Consent is account-holder granted, scoped to the data classes requested, time-boxed, and revocable by the customer at any time — and the strong-customer-authentication step is mandatory, which is why the mobile-authorisation PIN or biometric the app already enforces is part of the consent design rather than something bolted on. We keep access authorized and documented, log consent grants and revocations, minimise the data classes a project actually needs, and work under an NDA where the engagement calls for one. The EU's PSD3 and the Payment Services Regulation are in the legislative pipeline; we track that and design so a later move does not force a rebuild, without treating unsettled drafting as if it were in force.

Engineering realities we plan around

Three things about this app shape the work, and we account for each rather than hand them back as conditions.

The package is still pl.bzwbk.bzwbk24 while the brand, the public domain (santander.pl moving to erste.pl) and a planned core-platform migration onto Erste's own stack are all in motion. We pin the integration to stable identifiers and the regulated interface, and schedule a re-check of the captured flows whenever the app ships an update or a migration milestone lands, so a cosmetic or back-end shift does not quietly break a live sync.

The app ties every service to a single login and, as its own description says, deliberately stops several people sharing one install — quick preview, BLIK, tickets and parking are bound to that one identity. We design around one consented identity per account instead of assuming a poolable session, and we model the mobile-authorisation handshake (4-digit PIN, fingerprint or face) as a first-class step in the consent flow.

PolishAPI sessions and the External Authorization Tool carry their own expiry and re-confirmation rules. We map the decoupled EAT path and the consent-refresh window explicitly so a long-running aggregation re-confirms on schedule instead of failing on a stale token mid-cycle. Access itself is arranged with you during onboarding — the build runs against the bank's sandbox or a consenting account, whichever the project warrants.

How teams use it

• A bookkeeping platform importing categorised transactions for Mini Firma sole-proprietor clients straight into a ledger, with standing orders mapped to expected entries.
• A personal-finance app reproducing Financial Coach-style income and spend charts and Subscriptions detection across Erste alongside other Polish banks.
• A treasury tool polling balances and standing-order status across Erste and peers from one normalized schema.
• A marketplace reconciling BLIK payment events against orders, with limit and anomaly checks on the event stream.

Working with us, and what it costs

A working integration against Erste's account, transaction, card and BLIK surfaces is a one-to-two-week build. You can take the source outright — from $300 you receive the runnable code, the OpenAPI spec, the auth-flow report, tests and interface documentation, and you pay after delivery, once it runs and you are satisfied. Or you can call it as a hosted API priced per request, with no upfront fee and payment only for the calls you make. You bring the app name and what you want out of its data; we work out the route and arrange access and compliance with you. Start the conversation at /contact.html.

What was checked

This mapping was put together from the app's own Google Play description and feature list, the PolishAPI v2.1 specification for the AIS contract and OAuth2 details, the KNF and Polish Bank Association material on the PSD2 regime and AISP registration, and Polish press coverage of the Santander-to-Erste rebrand and ownership change. Primary sources: PolishAPI v2.1 specification (EN), PolishAPI — participating commercial banks, money.pl on the Santander-to-Erste switch, Erste Bank Polska — about.

Researched and written at the OpenBanking Studio integration desk, May 2026.

Other Polish banking apps in the same data picture

An aggregation or reconciliation pipeline rarely stops at one bank. These are the Polish retail apps that turn up alongside Erste, each holding broadly the same account, card and payment data behind its own login:

• IKO — PKO Bank Polski's app, Poland's most-used banking app, with broad public-service and BLIK coverage.
• mBank PL — mBank's app, long a Polish UX reference, holding accounts, cards and transfers.
• Moje ING — ING Bank Śląski's app, with strong product and budgeting coverage.
• PeoPay — Bank Pekao's app, accounts plus BLIK and phone transfers.
• Bank Millennium — Millennium's app, accounts, cards and a financial-summary surface.
• Alior Mobile — Alior Bank's app, retail accounts and payments.
• Citi Mobile — Citi Handlowy's app, retail accounts and cards in Poland.
• Revolut — a multi-currency account and card widely used in Poland alongside a primary bank.

Screens from the listing

Questions integrators ask about Erste

Does the legacy pl.bzwbk.bzwbk24 package ID change anything for an integration?

No. The package on Google Play still reads pl.bzwbk.bzwbk24 — the Bank Zachodni WBK, then Santander Bank Polska, now Erste Bank Polska lineage. We pin the integration to that stable identifier and the underlying account interface, so the cosmetic rebrand does not move the route.

Can the regulated PolishAPI channel return BLIK and Financial Coach data, or only core account data?

The AIS scope of PolishAPI carries balances, posted and pending transactions, account details and confirmation of funds. BLIK event detail, Subscriptions detection, Price advisor state and the Financial Coach analytics are app-derived surfaces — those come from the authorized interface-integration layer we build alongside the regulated feed.

Which Polish regulator and standard governs consented access to Erste accounts?

Poland transposed PSD2 through the Ustawa o usługach płatniczych, supervised by the Komisja Nadzoru Finansowego (KNF). The domestic interface standard is PolishAPI, maintained by the Polish Bank Association. A pure account-information provider registers in the KNF register rather than seeking full authorization.

We run a multi-bank aggregator in Poland — how does Erste's single-login model affect a consented sync?

The app ties services to one login and, as it describes, blocks several people from sharing the same install. We design the sync around one consented identity per account and fold the mobile-authorisation step — 4-digit PIN, fingerprint or face — into the consent flow, with the consent-refresh window scheduled so the connection does not lapse unnoticed.