Reaching Frankfurter Volksbank Rhein/Main account data through consented XS2A and FinTS

Frankfurter Volksbank Rhein/Main runs its mobile banking on the cooperative sector's shared platform, and the FVB Banking app puts an account overview, transfers, standing orders, the Wero instant-pay wallet and an encrypted Postfach in front of the customer. The data behind those screens is the interesting part for anyone building on top of it: balances and bookings that change through the day, P2P credits that arrive in seconds, and statement documents that drop into the inbox on a slower beat. The cleanest way to consume that is not one big nightly scrape — it is treating the fast surfaces as a stream of events you can replay, and pulling the slow ones on a schedule.

That split is the spine of how we would build it. Wero and SEPA Instant movements land as discrete events; balances and transaction history come from the regulated read interface under a consumer's consent; Postfach statements are fetched and parsed. Below is the data, the authorized routes, the code we hand over, and how an engagement runs.

What the app holds, and where it comes from

Each row is a surface the app actually exposes to its user, mapped to where the data originates and what an integrator typically does with it.

Routes into the data

Two authorized paths fit this bank, and they are complementary rather than either/or.

1. Berlin Group XS2A under PSD2 consent

The NextGenPSD2 standard is the de facto European access-to-account interface, and the German cooperative banks implement it. With a consumer's consent it reads account lists, balances and transaction history. Reachable: the core ledger surfaces. Effort: moderate — consent creation, strong customer authentication redirect, then paged reads. Durability: high, because it rides a regulated, supervised interface rather than anything brittle. We arrange the access path with you during onboarding and build against a sandbox or a consenting account.

2. FinTS / HBCI protocol mapping

FinTS, the Deutsche Kreditwirtschaft protocol that grew out of HBCI and is supported across the cooperative sector, can reach detail that the regulated read path does not always expose, under a customer's PIN/TAN authorization. Reachable: account turnover, balances, and some order detail. Effort: moderate — message construction and dialog handling. Durability: high; the standard is stable and widely deployed. We use this as a complement where a needed field is not available through XS2A.

Native export as a fallback

Where a one-off historical load is all that is needed, exported statement files (e.g. CAMT/MT940 from the Postfach) can seed the first backfill while the live route is wired. We treat this as a starter, not the running integration.

For an ongoing feed we would recommend anchoring on XS2A for the balance and transaction stream and reaching for FinTS only where a specific field is missing — that keeps the integration on the most durable interface while still getting the depth when a project needs it.

A consented balance-and-transaction pull

Illustrative shape of the XS2A read path, confirmed against the Berlin Group request style during the build. Consent is created, the customer authenticates, then transactions are paged and each booking is published onto a queue keyed by its booking reference so a consumer that lags can replay from its last offset without double-counting.

# 1) Create an account-information consent (consumer authorizes the scope)
POST /v1/consents
{
  "access": { "balances": [], "transactions": [] },
  "recurringIndicator": true,
  "validUntil": "2026-09-01",
  "frequencyPerDay": 4
}
-> 201 { "consentId": "c-…", "_links": { "scaRedirect": { "href": "…" } } }
# customer completes strong customer authentication at the scaRedirect URL

# 2) Page transactions for one account once consent is valid
GET /v1/accounts/{resourceId}/transactions?bookingStatus=booked&dateFrom=2026-05-01
Headers: Consent-ID: c-…, X-Request-ID: …
-> 200 {
  "transactions": {
    "booked": [
      { "transactionId": "b-9921", "bookingDate": "2026-05-28",
        "transactionAmount": { "amount": "-42.10", "currency": "EUR" },
        "creditorName": "…", "remittanceInformationUnstructured": "…" }
    ],
    "_links": { "next": { "href": "…&page=2" } }
  }
}

# 3) Fan each booking onto the queue; key on transactionId for replay-safe consumers
publish(topic="fvb.transactions",
        key=tx["transactionId"],
        value=normalize(tx))

# expired consent is a recoverable state, not an exception:
on 401 consent_invalid -> enqueue re_consent(customer_id); pause this account's poll
      

The same handler design covers Wero credits: the notification surface signals an arrival, the transaction read confirms it, and only the confirmed booking is published downstream.

What lands in your repo

The deliverable is working software, not a slide deck. For this app that means:

• Runnable source — a Python (or Node.js) client for the consent lifecycle, paged transaction reads, balance fetch and statement retrieval, with a normalizer that maps bookings into one schema.
• A queue/stream layer — publishers that emit each booking and Wero event keyed for replay, plus a consumer skeleton so a lagging service can resume from its last offset.
• Webhook / notification handlers — for the fast surfaces, wired to confirm-then-publish so nothing downstream acts on an unconfirmed event.
• An automated test harness — fixtures for consent expiry, paging, and malformed bookings, so a change in the upstream shape shows up as a failing assertion.
• Interface documentation — the field map, auth/consent flow, and the FinTS dialog notes where that route is used.
• Secondary, on request: an OpenAPI description of the normalized surface and a short auth-flow report.

Flows we build end to end

• Daily reconciliation feed — XS2A transaction reads each morning, normalized and pushed to an accounting system, with the prior consent state carried forward.
• Real-time arrival alerts — Wero and SEPA Instant credits surfaced as events within seconds of confirmation for a treasury or notification service.
• Statement archive — Postfach documents pulled, parsed into structured rows, and filed against the right account.
• Multi-account aggregation — one customer's accounts at FVB combined with accounts at other institutions behind a single normalized ledger.

Consent, BaFin and the PSD2 basis

The dependable basis for this work is the account holder's own authorization. Under PSD2, account-information access is given by the consumer through an explicit consent with a defined scope and lifetime, and a third party reading on their behalf operates as an account information service with the appropriate eIDAS certificate and the PSP_AI role. In Germany this is supervised by BaFin, and the technical interface follows the Berlin Group NextGenPSD2 standard. Consent has a fixed validity and requires periodic re-authentication; revocation is the customer's to exercise at any time. We operate authorized, log access against the consent record, keep the data set to what the use case needs, and work under an NDA where a project calls for one. Where FinTS is used, the customer's PIN/TAN authorization is the basis, handled the same way.

What we plan around for this app

Two specifics shape the build, and we account for both rather than handing them back to you as conditions:

• Consent expiry against a continuous feed. A PSD2 consent expires and SCA recurs, which can stall a running sync. We design the scheduler to track each consent's window and prompt the end user to re-consent before it lapses, so the feed keeps its place instead of going quiet.
• Shared-platform routing. Frankfurter Volksbank Rhein/Main shares the cooperative sector's banking backend, so the integration resolves to this specific institution by its bank code rather than by anything app-branding-specific. We pin the routing to the right institution and verify it during onboarding so transactions are never read against the wrong endpoint.
• Replay without duplication. Because the fast surfaces are streamed, we key every published event on its booking or transaction reference, so a consumer that reprocesses a window settles to the same state rather than counting a credit twice.

Access, sandbox or consenting-account setup, and any certificate paperwork are arranged with you during onboarding — that is part of the engagement, not something to clear before we start.

Working with us

You hand over the app name and what you want out of its data; the rest is ours. Source code lands first and you pay after — source-code delivery starts at $300, billed once you have the working integration in hand and are satisfied with it. If you would rather not host anything, the alternative is our pay-per-call hosted API: you call our endpoints, pay only for the calls you make, and there is no upfront fee. Either way the cycle is one to two weeks. Tell us the surfaces you care about and we will scope it. Start a conversation here.

Interface evidence

Screens from the app's store listing, used to map the surfaces above. Select one to enlarge.

Neighbouring apps in the German banking landscape

Other apps an aggregation or reconciliation project tends to touch alongside this one. Listed for context, not ranked.

• VR BankingApp — the cooperative sector's shared app; holds the same class of account and transaction data on the same platform family.
• Sparkasse — the savings-bank group's app, with accounts, transfers and statements behind a separate sector backend.
• N26 — Berlin neobank; per-user balances, transactions and spaces, app and web.
• bunq — app-first bank with German IBANs and a rich transaction and sub-account model.
• Revolut — multi-currency accounts, cards and transaction history across personal and business tiers.
• Wise — multi-currency balances and low-cost transfers, with detailed transfer records.
• Commerzbank — full-service bank app covering accounts, payments and brokerage data.
• Deutsche Bank Mobile — accounts, cards and investment positions for a large retail base.
• DKB — direct bank with accounts, cards and securities data.
• Comdirect — brokerage-leaning app with accounts plus depot and order data.

Questions integrators ask

Can we receive Wero and SEPA Instant activity as a stream instead of polling balances all day?

Yes. We model the fast-moving surfaces (Wero credits, SEPA Instant, card authorizations) as events published onto a queue, with each event carrying a stable reference so a consumer that falls behind can replay from the last processed offset. Slower surfaces like Postfach statements are pulled on a schedule. You decide the split; we wire both.

Do you build against the Berlin Group XS2A interface or the FinTS protocol, and when does each make sense?

Both are on the table. XS2A under the NextGenPSD2 standard is the regulated read path for accounts, balances and transactions with a consumer's consent. FinTS/HBCI, the long-standing German cooperative-sector protocol, can reach richer detail where a customer authorizes a PIN/TAN session. We usually anchor on XS2A for durability and add FinTS where a field XS2A does not expose is needed.

What happens to a long-running sync when strong customer authentication or the consent expires?

PSD2 consent has a fixed lifetime and re-authentication is required periodically. We design the sync to track each consent's expiry and to surface a re-consent prompt to the end user before the window closes, so the feed does not stall mid-cycle. The handler treats an expired consent as a recoverable state, not a crash.

Is the Rhein/Main app meaningfully different to integrate than the generic VR BankingApp?

For the data path, no — Frankfurter Volksbank Rhein/Main runs on the shared cooperative-sector banking platform, so the XS2A endpoints and FinTS routing resolve to that institution by its bank code. The app branding differs; the underlying account-access interface is the sector standard, which is what we integrate against.

Sources & method

Checked on 1 June 2026 against the app's own store and bank descriptions and the primary standards bodies, then mapped to the routes above. The Berlin Group NextGenPSD2 materials confirm the XS2A interface; Deutsche Kreditwirtschaft confirms FinTS as the cooperative-sector protocol; the Play and bank listings confirm the app's surfaces (Wero, kiu, Postfach, account overview). Sources opened:

• Berlin Group — NextGenPSD2 downloads
• Deutsche Kreditwirtschaft — FinTS
• Google Play — Frankfurter Volksbank Banking
• Frankfurter Volksbank — FVB Banking app functions

Compiled by OpenFinance Lab's integration engineering team on 2026-06-01.