Pulling balances, transactions and Wero history out of VR Banking

At a glance

Behind the single icon on the Play Store — package de.fiduciagad.banking.vr, per its listing — sits Atruvia's shared core banking platform, the system Atruvia says administers on the order of 82 million cooperative-bank accounts across Germany. The VR Banking app puts that platform in a customer's pocket for the local Volksbanken and Raiffeisenbanken. An integrator rarely wants the screen; they want the record behind it.

What that usually means in practice is the history: every booked and pending entry, the running balance, standing orders, and the newer Wero account-to-account movements — pulled once as a backfill, then kept current. The way in we would take is the regulated access-to-account interface those banks already run under PSD2: authorised once by the account holder, then read on a schedule. The build centres on a consented backfill through that interface, with an incremental delta after it.

What the account actually holds

The app names most of these surfaces in plain terms. Here is where each one originates and what it is good for downstream.

Routes into the cooperative-bank backend

Three doors apply here, with different effort and durability. They are not mutually exclusive — a real build often uses two.

1 · PSD2 XS2A consent (the spine)

The Berlin Group NextGenPSD2 access-to-account interface, with the Deutsche Kreditwirtschaft additions German banks layer on, reaches the account list, balances, booked and pending transactions, and standing orders, plus payment initiation if you need it. Effort is moderate: the consent handshake, the SCA redirect into the VR app, and pagination are standard, and the per-cooperative-bank routing is the part that takes setup. Durability is high — BaFin requires the banks to keep this interface running, so it does not move under you on a vendor's release schedule. Access, the eIDAS certificates and a sandbox are arranged with you during onboarding, under a licensed AISP in the chain.

2 · FinTS / HBCI (the mature fallback)

FinTS, the Deutsche Kreditwirtschaft homebanking protocol first published in the 1990s, is still served by around two thousand German institutions per the DK. It returns balances and transactions reliably and is well documented. Its weak point is consent: FinTS does not natively carry the unattended, time-boxed authorisation that XS2A does, so it suits a supplement where a particular small cooperative bank's XS2A coverage lags rather than the primary feed.

3 · Authorised protocol analysis

For surfaces the regulated interface does not carry — Wero history detail, inbox PDFs, the CO₂Check view — we analyse the app's own traffic under your authorization. Reach is broad, durability lower, since it tracks app releases. We reach for it only where a surface is genuinely app-only.

For most projects the sensible shape is XS2A for balances, transactions and standing orders, FinTS held in reserve for the handful of banks whose XS2A is thin, and protocol analysis kept narrowly for the app-only screens. We say which, for your bank list, before any code is written.

The consented read, request by request

This is the shape of the XS2A flow as the cooperative-bank interface exposes it — consent first, then a dated transactions pull that pages back through history. Values are illustrative and confirmed against the Berlin Group spec during the build.

# 1) Open a consent. The customer authorises in the VR Banking app via SCA.
POST /v1/consents
  PSU-IP-Address: 198.51.100.7
  TPP-Redirect-URI: https://your.app/cb
  {
    "access": {
      "balances":     [ { "iban": "DE.." } ],
      "transactions": [ { "iban": "DE.." } ]
    },
    "recurringIndicator": true,
    "validUntil": "2026-09-06",     # bounded by the EBA RTS re-auth cadence
    "frequencyPerDay": 4
  }
-> 201 {
     "consentId": "CON-9f2a..",
     "consentStatus": "received",
     "_links": { "scaRedirect": { "href": "https://aspsp/.." } }
   }

# 2) After authorisation, read transactions from a start date and page back.
GET /v1/accounts/{resourceId}/transactions?dateFrom=2024-01-01&bookingStatus=both
  Consent-ID: CON-9f2a..
-> 200 {
     "transactions": {
       "booked": [
         { "transactionId": "T-0481..",
           "bookingDate": "2026-05-30",
           "valueDate":   "2026-05-31",
           "transactionAmount": { "currency": "EUR", "amount": "-42.10" },
           "remittanceInformationUnstructured": "Wero • split dinner" }
       ],
       "pending": [ ".." ],
       "_links": { "next": { "href": "/v1/accounts/../transactions?page=2" } }
     }
   }
# Follow _links.next to backfill; on later runs, set dateFrom to the last cursor.
      

Folding every entry into one schema

XS2A booked and pending records, FinTS rows where used, and Wero movements all collapse into a single normalized shape so downstream code never branches on the source. A dedup key built from the bank's transactionId means an overlapping backfill window merges to one row rather than two.

{
  "account_iban": "DE.. (masked at rest)",
  "booked_at":    "2026-05-30",
  "value_date":   "2026-05-31",
  "amount_cents": -4210,
  "currency":     "EUR",
  "counterparty": { "name": "..", "iban": ".." },
  "kind":   "sct_inst | sepa_dd | card | wero | standing_order",
  "status": "booked | pending",
  "source": "xs2a | fints",
  "dedup_key": "sha1(bank_id + transaction_id)"
}
      

What lands in your repository

The headline is code that runs, not a document set. In order:

• Runnable Python and Node.js clients for the consent → accounts → transactions flow, with the SCA redirect handled and pagination built in.
• A backfill job plus incremental delta sync — cursored on booking date and the next links — with the dedup key so re-pulled windows merge cleanly.
• An automated test suite: fixtures captured from the sandbox and contract tests that assert the XS2A response shapes your code leans on.
• A normalization layer mapping XS2A booked/pending (and FinTS, where used) into the schema above.
• An OpenAPI / Swagger description of the endpoints you actually call.
• A protocol and auth-flow report: the consent and SCA redirect chain, token lifetimes, and the per-cooperative-bank routing table.
• Consent-lifecycle and data-retention notes, plus the interface documentation to maintain it.

Consent, BaFin oversight, and the EU's next step

The dependable basis today is the account holder's own consent under PSD2, which Germany supervises through BaFin and the ZAG. Consent is explicit, scoped to the accounts and data types the customer ticks, time-boxed, and revocable in the app at any moment; access runs through the bank's XS2A interface under strong customer authentication, with the EBA's regulatory technical standards setting how often the customer must re-authenticate. We operate authorised and logged — a licensed AISP in the chain, eIDAS certificates on the calls, consent records kept, data minimised to the use case, NDAs where a client wants them.

Where this is heading is the EU's Financial Data Access regulation, FiDA, which would extend consented sharing past payment accounts into savings, investments and more. As of mid-2026 FiDA is still in negotiation — proposed by the Commission in 2023, reshaped across 2024 and 2025, with first obligations expected only well after adoption — so it is the direction of travel, not something this integration depends on. The build stands on the PSD2 consent the cooperative banks already serve.

What we plan around for this app

A few things about VR Banking specifically shape the build, and we account for each rather than handing them to you as homework.

One app, hundreds of banks

Every Volksbank and Raiffeisenbank is a legally separate credit institution sharing Atruvia's platform, so a single VR Banking login can belong to any one of them. We build the routing that resolves a consent to the correct institution's XS2A base URL from the customer's IBAN and BIC, so one integration covers the group instead of a single branch.

The multibanking accounts are a different door

The account overview already aggregates accounts the customer holds at other banks. We settle up front whether you want only the cooperative-bank accounts or the full aggregated set, because the external ones arrive through their own ASPSPs and their own consents — separate base URLs, separate coverage — not Atruvia's interface.

Consent that lapses on a clock

PSD2 consent does not last forever, and the customer can withdraw it in the app. We schedule the re-authorisation prompt ahead of the window closing and model a revoked consent as a first-class state, so a lapse turns into a clean prompt to re-consent instead of a sync that quietly stops returning rows.

Wero looks like an ordinary transfer until you tag it

Wero settles as SEPA Instant account-to-account entries, not as a card rail, so in the raw feed it reads like any other SCT Inst credit or debit. We tag it during normalization from the counterparty and channel hints, so your downstream can tell a Wero split from a routine transfer.

From the app's own screens

The published screenshots, for reference on which surfaces the integration maps to. Tap to enlarge.

Neighbouring German banking apps

If you are aggregating, VR Banking is one node among several that share the same German interfaces. Each holds its own account data; an integration that normalizes one is a short step from the next.

• Sparkasse (Sparkassen-App) — the savings-bank group's counterpart, on the same XS2A basis and often the other side of a multibanking view.
• Deutsche Bank Mobile — a large-bank app that itself offers multibanking aggregation across other institutions.
• ING (formerly ING-DiBa) — direct-bank app with current and savings accounts reachable over the same PSD2 interface.
• DKB — direct bank whose accounts integrators commonly pull alongside cooperative-bank ones.
• Comdirect — Commerzbank-group direct bank pairing brokerage with banking, account data behind XS2A.
• N26 — mobile-first bank holding a full BaFin licence; payment-account data flows over PSD2.
• Trade Republic — broker-bank with cash accounts and securities; the cash side is reachable over PSD2.
• Finanzguru — an aggregator that consumes XS2A feeds from banks like this one rather than holding the primary account.
• Outbank — a long-running German multibanking client pulling accounts across institutions via FinTS and PSD2.
• StarMoney — another established multibanking app aggregating accounts over the same German interfaces.

Questions integrators bring us

VR Banking already shows accounts from other banks — can you pull those too?

Yes, but they come through a different door. The in-app multibanking view aggregates external accounts through each of those banks own XS2A consents, not Atruvia's. We can include them, each under its own consent and routed to the right institution; we agree the account list with you up front.

Can you backfill years of history, or only the latest statement page?

We backfill. The XS2A transactions call takes a dateFrom and returns pages linked by a next reference, so the client walks back as far as the bank exposes — commonly a couple of years of booked entries — then switches to an incremental delta inside the consent window. How far back is reachable depends on the individual cooperative bank's retention.

Each Volksbank is a separate bank — does one integration cover all of them?

One integration, with routing underneath. Because every cooperative bank is its own ASPSP on the shared Atruvia platform, the client resolves the customer's bank from their IBAN and BIC and calls that institution's XS2A endpoint. You get one client that handles the group, not one build per branch.

Do Wero transfers show up in the feed?

They do, as SEPA Instant account-to-account entries rather than a separate rail. We tag them during normalization, using the counterparty and channel hints, so a Wero send or request stays distinguishable from an ordinary transfer in your data.

Sources behind this page

Put together on 8 June 2026 against the app's Play Store listing and the cooperative group's own pages, the Berlin Group's access-to-account documentation, the European Commission's FiDA page, and EPI's Wero material. Where a figure comes from a vendor — Atruvia's account count, EPI's Wero adoption numbers — it is their published figure, cited as such, not ours.

• Berlin Group — PSD2 Access to Bank Accounts (XS2A)
• European Commission — Framework for Financial Data Access (FiDA)
• Volksbanken Raiffeisenbanken — VR Banking App
• Wero (EPI) — overview and rollout

Mapped and written by OpenFinance Lab's integration engineering, 8 June 2026.

A first working client for the consent-and-backfill flow usually lands within one to two weeks. You can take it as source you keep — runnable code, tests and documentation from $300, paid after delivery once it does what you need — or skip hosting it and call our endpoints instead, metered per call with nothing upfront. Tell us the app and what you want out of its data at /contact.html; the access, certificates and sandbox get arranged with you from there.