BKS Bank App: reaching accounts, cards, and securities through Austria's AIS layer

Austria's ZaDiG 2018 and what it opens for BKS Bank

Austria transposed PSD2 into national law as the Zahlungsdienstegesetz 2018 (ZaDiG 2018). The FMA supervises all Austrian credit institutions under this framework, including BKS Bank AG. Licensed Account Information Service Providers (AISPs) can request consent-based access to payment-account data: balances, transaction histories, and standing orders. The consent scope, SCA re-authentication window (per the FMA's implementation of the 90-day rule), and revocation mechanics are all governed by ZaDiG 2018.

BKS Bank's XS2A interface follows the Berlin Group NextGenPSD2 standard. Technical support for the interface is handled by finAPI, and a sandbox environment has been available since 2019 for AISP and PISP testing. Data minimization applies: only accounts the end user explicitly consents to are exposed.

For data outside the PSD2 perimeter — custody accounts, securities portfolios, card-limit settings, GeoControl toggles — the route is authorized protocol analysis under the account holder's direct consent, arranged with the client during onboarding and covered by an NDA where needed.

Account and securities data inside BKS Bank App

The first five rows fall inside PSD2 AIS scope. Custody positions and card-management state do not, and require protocol-level access.

Routes into the BKS interface layer

Route 1 — PSD2 AIS via XS2A (Berlin Group NextGenPSD2)

Covers payment-account balances, transaction history, SEPA order status, and standing orders. The XS2A interface is live. finAPI manages the technical bridge. Effort is moderate: consent-flow integration, SCA handling, and token lifecycle are well-documented. Durability is high — this is a regulatory mandate, not a voluntary feature. We handle AISP onboarding with the client and build against the sandbox before cutting over to production consent.

Route 2 — Authorized protocol analysis of the app session

Reaches everything the app renders: custody accounts, securities portfolios, card POS/ATM limits, GeoControl state, the currency converter, and branch/ATM data. Effort is higher — it requires mapping the app's authenticated session and building a request-replay layer. Durability depends on the app-release cadence; we build with version detection and graceful fallback. Access is arranged during onboarding against a consenting account.

Route 3 — User-consented credential access via the MyNet portal

The browser-based MyNet internet-banking portal exposes the full surface, including securities orders and card settings. Effort is moderate: the portal has a stable DOM, and BKS Bank's SecurityCard flow for transaction authorization is well-understood. We set up headless-browser session management, SecurityCard challenge handling, and a data-extraction pipeline. Portal redesigns are infrequent for regional banks.

For most integrators, the practical path starts with the XS2A AIS interface for payment-account data and layers protocol analysis on top for custody and card-management surfaces that PSD2 does not cover. The MyNet portal serves as an independent verification channel and a fallback for edge-case data that the app session does not expose.

Deliverables for a BKS Bank integration

• OpenAPI 3.x specification mapping every reachable endpoint — balances, transactions, custody positions, card state
• Protocol and auth-flow report documenting the OAuth / SCA / SecurityCard chain as it runs for BKS Bank
• Runnable Python or Node.js source for the key data-pull endpoints, including consent lifecycle management and error handling
• Automated test suite verifying each surface against the BKS sandbox and a live consenting account
• Interface documentation with data schemas, field mappings, refresh intervals, and rate-limit notes

AIS balance request against BKS Bank's XS2A

# Illustrative — actual host confirmed during onboarding
# Follows Berlin Group NextGenPSD2 pattern used by BKS Bank

import requests

BASE = "https://xs2a.bks.example/psd2/v1"
CONSENT_ID = "<granted-consent-id>"
TOKEN = "<access-token>"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Consent-ID": CONSENT_ID,
    "X-Request-ID": "unique-uuid-per-call",
    "Accept": "application/json",
}

resp = requests.get(f"{BASE}/accounts", headers=headers)
if resp.status_code == 401:
    # Token expired — trigger SCA re-authentication
    raise RuntimeError("Access token expired; re-run consent flow")

accounts = resp.json().get("accounts", [])

for acct in accounts:
    bal = requests.get(
        f"{BASE}/accounts/{acct['resourceId']}/balances",
        headers=headers,
    )
    for b in bal.json().get("balances", []):
        print(f"{acct['iban']}  {b['balanceType']}: "
              f"{b['balanceAmount']['amount']} "
              f"{b['balanceAmount']['currency']}")

The snippet above reflects the Berlin Group NextGenPSD2 balance-query pattern. Field names, response shapes, and error codes are confirmed against BKS Bank's sandbox during the build.

Integration scenarios for BKS Bank data

Multi-bank treasury across the 3 Banken Gruppe. A corporate client banking with BKS, Oberbank, and BTV needs a single cash-position dashboard. The integration pulls payment-account balances from all three XS2A endpoints, normalizes the response schema (which is closely related across the group's shared IT), and outputs a unified feed with per-bank consent tracking.

Securities portfolio sync. A wealth-management platform wants nightly custody snapshots — ISIN, quantity, valuation date, unrealized gain/loss — from BKS Bank's Depot section. PSD2 AIS does not cover securities. We reach this surface through protocol analysis of the authenticated session and deliver it alongside the payment-account feed in a single normalized output.

Travel-policy automation. An expense-management tool reads the GeoControl and POS/ATM limit state on an employee's BKS Maestro card, toggling it programmatically when the employee's itinerary changes. The write path includes a confirmation step and audit trail to prevent accidental lockouts.

Engineering specifics for this build

The 3 Banken Gruppe shares infrastructure through 3 Banken IT GmbH, so session tokens, cookie formats, and internal data schemas follow a common pattern across BKS, Oberbank, and BTV. Each bank's XS2A endpoint is separately registered with the FMA and carries its own consent domain. We map this divergence upfront so a client covering all three banks gets one integration with per-bank consent routing, not three duplicated builds.

BKS Bank's SecurityCard mechanism runs a challenge-response cycle that differs from the SCA flow in the XS2A consent path. For protocol-analysis routes that touch payment initiation or card management, we handle the SecurityCard challenge programmatically and design the session to distinguish read-only operations (no SecurityCard) from write operations (SecurityCard required). The separation is clean once mapped, but the mapping is where the engineering work sits.

The app's GeoControl setting — enabling or disabling international card use on a Maestro card — is a mutable flag with no PSD2-equivalent endpoint. We treat it as a write-capable surface: the integration reads current state and can toggle it, but we build a confirmation step and audit trail so the client's system does not inadvertently lock out a cardholder abroad.

BKS Bank App interface

Austrian banking apps in the same integration category

George (Erste Bank und Sparkassen) — Austria's largest retail banking app; covers accounts, savings, securities, and bill payments, with a PSD2-compliant XS2A interface via Erste Group.

Bank Austria MobileBanking — UniCredit's Austrian arm, offering similar account and transfer surfaces under FMA/PSD2 supervision.

Raiffeisen ELBA — Raiffeisen Bankengruppe's internet-banking frontend, strong in agricultural and SME lending, with transaction and loan data behind its portal.

BAWAG P.S.K. — Austrian retail bank with consumer loans and insurance products alongside standard payment accounts.

Oberbank — 3 Banken Gruppe sister bank; shared IT layer means closely related session architecture and data schemas, with its own XS2A endpoint and FMA licence.

BTV Banking — The third 3 Banken Gruppe member, operating across Tyrol, Vorarlberg, southern Germany, and eastern Switzerland, with custody and securities surfaces similar to BKS Bank's.

N26 — Berlin-based mobile bank licensed in Germany and operating across the EEA, with real-time transaction notifications and a well-documented XS2A.

Revolut — UK-headquartered neobank with multi-currency accounts; offers AIS-level data under PSD2 in the EEA.

easybank — Now part of BAWAG, formerly Erste Group; consumer-focused with checking and savings accounts.

Questions integrators ask about BKS Bank App

Does BKS Bank expose an XS2A interface that supports account-information access?

Yes. BKS Bank's XS2A interface follows the Berlin Group NextGenPSD2 standard and is supported by finAPI. A sandbox has been available since 2019 for testing AIS and PIS flows. We build against this interface and deliver runnable source code that handles the consent, token, and polling lifecycle.

Can custody and securities-portfolio data be pulled alongside payment accounts?

PSD2 AIS covers payment accounts: balances, transactions, and SEPA orders. Custody and securities data sit outside the AIS scope, so we reach them through authorized protocol analysis of the authenticated app session. Both feeds are delivered as a single normalized output.

How does the BKS SecurityCard affect the integration flow?

BKS Bank uses a SecurityCard for transaction authorization, the same mechanism as its MyNet internet banking. For read-only AIS access, strong customer authentication runs during the consent grant and no SecurityCard step is needed per-request after that. For payment initiation, each order triggers an SCA challenge that the integration handles programmatically.

Is there a difference integrating BKS Bank versus Oberbank or BTV from the 3 Banken Gruppe?

All three banks share backend IT through 3 Banken IT GmbH, so the session architecture and data schemas are closely related. The XS2A endpoints differ per bank, and each has its own FMA-supervised licence and consent domain. We can scope a single engagement to cover all three if the client needs a unified feed across the group.

Sources and review date

This page was compiled from BKS Bank's published XS2A documentation, the FMA's supervisory-authority pages, PSA Payment Services Austria's XS2A API directory, and the app's Play Store listing. Key sources:

• BKS Bank — XS2A Schnittstelle (PSD2)
• FMA — Banks supervision
• PSA Payment Services Austria — XS2A / API
• Austria Open Banking — PSD2 regulations and status

OpenBanking Studio · integration mapping, June 2026.

For BKS Bank App, the deliverable is runnable source code covering the AIS consent lifecycle, session-level protocol for custody data, and a unified output schema — from $300 for source-code delivery, paid after you are satisfied with the build, or as a pay-per-call hosted endpoint with no upfront fee. Typical turnaround is one to two weeks from the app name and your requirements to working code. Get in touch to scope the build.