Connecting to VR Banking accounts, standing orders and Wero flows

Every VR Banking install sits in front of a cooperative-bank core run by Atruvia (the former Fiducia & GAD IT), so the data a third party wants is not in the app at all — it is account state held server-side and surfaced through a session. Balances, the booked-and-pending transaction list, scheduled and real-time transfers, standing orders, Kontoauszug statements, the bank-message inbox, and Wero account-to-account events all originate behind authentication. The work of an integration is choosing the authorized door to that state and writing the client that walks through it.

The cleanest read path is the regulated one. A German cooperative bank operates an access-to-account interface, and the balance and transaction reads the app shows a customer are the same reads a consented account-information client can request. Where a project needs more than reads — initiating transfers, working standing orders, or touching surfaces the app keeps to itself such as Wero and the statement archive — we add FinTS and authorized protocol analysis to cover what the standardized read scope does not. The recommendation for most VR Banking projects is to anchor balances and transactions on XS2A consent because it is durable and standardized, then reach Wero, inbox and statement documents through analyzed app traffic, since those never appear on the consent interface.

What the app holds

Each row maps to something a customer actually sees in the app, which is what makes the integration scoping concrete rather than a guess. The split that matters most: the first four rows largely live on the regulated read interface, while statements, inbox and Wero sit only inside the app session.

Authorized routes

1 — PSD2 XS2A consent (Berlin Group NextGenPSD2)

The Berlin Group's NextGenPSD2 framework is the de facto XS2A standard across European banks, and it defines the calls an account-information client needs: establish a consent, list reachable accounts, read balances, read transactions. Reachable here are balances and the transaction history — commonly around a 90-day window before strong customer authentication is renewed. It is durable because it is regulated and versioned rather than scraped. We set up the AISP role for the project, working as or with a licensed account-information provider and registering the redirect and certificate material with you during onboarding.

2 — FinTS (the HBCI successor)

FinTS, maintained by the Deutsche Kreditwirtschaft and widely supported across Volksbanken and Raiffeisenbanken, carries account queries, transfers and standing orders over PIN/TAN. We reach for it when a project needs operations the XS2A read scope does not cover, and it has the advantage of being a long-standing multi-bank German interface rather than a per-bank custom path.

3 — Authorized protocol analysis of the app session

Surfaces the app keeps to itself — Wero events, the statement archive, inbox messages, push-alert configuration — are reached by analyzing the app's own traffic under your authorization, on a consenting account. This is reverse engineering for interoperability: we document the auth handshake and the request shapes, then deliver a client that calls them. SecureGo plus handles the second factor in this family, so the flow design accounts for an external authorization step.

4 — Native statement export

Where a use case only needs the Kontoauszug documents, the in-app statement archive is the lightest path and we wire a fetch-and-store job around it. It is a fallback that pairs well with a consent-based transaction feed.

What lands in your repo

A VR Banking engagement ships as working software, not a slide deck. Concretely:

• An OpenAPI description of the normalized endpoints we expose to you — accounts, balances, transactions, standing orders, statements — so your side codes against one stable contract regardless of which route fills it.
• A protocol and auth-flow report covering the XS2A consent lifecycle, the FinTS dialog where used, and the analyzed app handshake including the SecureGo plus second factor.
• Runnable source for the key reads in Python and Node.js: consent creation, account listing, transaction pull, and the statement and Wero fetchers.
• Automated tests against recorded fixtures so a consent expiry or a changed field surfaces as a failing test, not a silent gap.
• Interface documentation and a data-retention note describing what is logged, what is minimized, and how consent records are kept.

A consent call, in code

Illustrative NextGenPSD2 shapes for the read path; field names follow the Berlin Group model and are confirmed against the target interface during the build.

POST /v1/consents HTTP/1.1
Host: xs2a.<vr-bank-aspsp>.de
X-Request-ID: 2f9b1c44-...-e1
PSU-IP-Address: 198.51.100.7
TPP-Redirect-URI: https://client.example/cb
Content-Type: application/json

{
  "access": { "balances": [], "transactions": [] },
  "recurringIndicator": true,
  "validUntil": "2026-09-05",
  "frequencyPerDay": 4
}

# 201 Created
{
  "consentStatus": "received",
  "consentId": "c-7f31a2...",
  "_links": { "scaRedirect": { "href": "https://login.../auth" } }
}

# after the customer completes SCA, read bookings
GET /v1/accounts/{resourceId}/transactions?bookingStatus=booked
Consent-ID: c-7f31a2...
X-Request-ID: 9a14d0e2-...

# 200 -> { transactions: { booked: [ { transactionAmount, creditorName,
#          bookingDate, remittanceInformationUnstructured } ], _links } }

Error handling matters as much as the happy path: a 401 with CONSENT_INVALID drives a re-consent, and a 429 backs off against the per-day frequency cap. We code those branches rather than assume the first response.

Consent and German oversight

PSD2 is implemented in Germany through the Zahlungsdiensteaufsichtsgesetz, with BaFin authorizing and registering providers and the Bundesbank involved in payment-system oversight; a firm offering account-information services registers with BaFin rather than holding a full payment licence. The dependable basis for every route here is the account holder's own consent — granted, scoped, and revocable. XS2A consent carries an explicit validity window and a daily access frequency, and strong customer authentication renews it, so the integration is designed to re-consent cleanly rather than break at expiry. Personal data falls under the GDPR and the German BDSG, which is why the build minimizes what it stores and keeps consent and access logs. The app describes itself as TÜV Saarland certified; we treat its security posture as a constraint to work within, not around.

Build notes we plan around

Two specifics shape a VR Banking build, and we handle both as part of the work.

First, the multi-bank overview is an illusion of one feed. The app shows accounts held at other banks, but XS2A consent is granted per ASPSP, so we issue and refresh one consent per institution and merge the results into a single normalized account list on our side — the cooperative-bank federation means the access-to-account endpoint can differ between member banks, and we map that per institution.

Second, the second factor lives outside the banking app. Authorization in this family runs through SecureGo plus, so the consent and session flow is built around an external approval step rather than an inline password, and the sync is scheduled around the consent-refresh window so it does not quietly lapse. Access to a consenting account or a sponsor sandbox is arranged with you during onboarding, and we wire a re-validation pass into maintenance so a change in the app front end or the XS2A version shows up as a caught regression.

Where teams use this

• An accounting tool that pulls booked transactions nightly across a member's VR-Bank and external accounts for automatic reconciliation.
• A treasury dashboard that reads balances and standing orders to forecast recurring outflows.
• A personal-finance app that mirrors statements from the Kontoauszug archive into long-term storage the bank does not retain indefinitely.
• A merchant flow that reconciles incoming Wero account-to-account receipts against the live transaction view.

Cost and timing

Pricing is the same for VR Banking as for any target, and it is short. Source-code delivery starts at $300: you receive the runnable client, the OpenAPI contract, the tests and the documentation, and you pay after delivery once the integration is working to your satisfaction. The alternative is the pay-per-call hosted API, where we run the endpoints and you are billed only for the calls you make, with no upfront fee. A typical build runs one to two weeks. Tell us the app — VR Banking - einfach sicher — and what you need from its data; the access and compliance setup is arranged with you from there. Start a VR Banking integration.

Sources checked

Drafted in June 2026 from the app's own Play Store description and from primary material on the German open-banking regime: the Berlin Group XS2A framework, BaFin's PSD2 pages, and the EPI Wero scheme. Citations:

• Berlin Group — PSD2 Access to Bank Accounts (NextGenPSD2)
• BaFin — Payment services and PSD2
• Wero (EPI account-to-account scheme) — overview
• VR Banking - einfach sicher — Google Play listing

Reviewed 2026-06-07 by the OpenBanking Studio integration desk.

Other German banking apps

Same category, named for context and to show how a unified integration spans them — not a ranking.

• Sparkasse — the savings-banks app, holding accounts, transactions and transfers behind a comparable XS2A interface.
• N26 — a Berlin digital bank with app and web access to accounts and card activity.
• Deutsche Bank Mobile — private-customer transfers, balances and portfolio data.
• Commerzbank Banking — accounts, transfers and photoTAN-based authorization.
• Postbank — retail accounts and payments under the Deutsche Bank group.
• ING Banking to go — accounts, transfers and securities for the German ING customer base.
• DKB — direct-bank accounts, cards and transaction history.
• comdirect — brokerage and current-account data in one app.

Questions integrators ask

Does XS2A reach the accounts at other banks that VR Banking aggregates, or only the Volksbank account?

XS2A consent is granted per ASPSP, so the consent issued against a VR-Bank access-to-account interface returns that institution's accounts. The multi-bank overview the app shows is itself an aggregation built on separate consents at each bank, and we reproduce that pattern: one consent and one transactions pull per institution, normalized into a single account list on our side.

How does Wero fit an integration when it settles account-to-account with no IBAN entry?

Wero is an EPI account-to-account scheme routed over SEPA Instant, addressed by phone number or email rather than IBAN, and it lives inside the app rather than on the XS2A surface. Reaching Wero send, request and history events is an authorized protocol-analysis task against the app's own traffic, run under your authorization on a consenting account; the resulting bookings are reconciled back to the account view that XS2A or FinTS already exposes.

Which German interface standards apply besides PSD2 XS2A?

FinTS, the standard that grew out of HBCI and is maintained by the Deutsche Kreditwirtschaft, is widely supported across Volksbanken and Raiffeisenbanken for account queries, transfers and standing orders over PIN/TAN. We use FinTS where an integration needs deeper account operations than the XS2A read scope offers, and XS2A where standardized balance and transaction reads under consent are enough.

Can the account statements and inbox messages the app stores be pulled, not just the live transaction list?

The Kontoauszug statements and the bank-message inbox are document surfaces the app keeps server-side and exposes only inside its own session. XS2A returns booked and pending transactions, not the rendered statement PDFs, so statement and inbox retrieval is handled through authorized protocol analysis of the app session and delivered as a documented fetch-and-parse step alongside the consent-based reads.

App profile

VR Banking - einfach sicher is the mobile banking app of the German cooperative banks (Volksbanken Raiffeisenbanken), built on the Atruvia / former Fiducia & GAD IT platform, with the package id de.fiduciagad.banking.vr per its Play Store listing. It gives 24/7 access to accounts — including accounts held at other banks — with a customizable transaction view, real-time and scheduled transfers, photo transfer from scanned slips or QR codes, standing-order management, account statements and a bank-message inbox, push notifications, digital girocard payments, and Wero account-to-account transfers addressed by phone or email. Additional features include mobile top-up, a tax-exemption order, an ATM/branch finder and a CO₂ footprint check. The listing states the app is TÜV Saarland certified. It is available on Android and iOS.

Interface evidence