Reaching VR cooperative-bank account data when VR SecureGo plus holds the release

When a transfer is submitted in VR online banking or the VR Banking app, the release does not happen in the browser. It surfaces as a push approval inside VR SecureGo plus, where the customer confirms it with a release code or Face ID. That single design fact decides how any third party reaches the account data behind it: the authorization channel is out of band, run through this app, and the readable data sits on the Volksbanken Raiffeisenbanken online-banking backend operated by Atruvia AG. This brief maps that data, the authorized route to it, and what we hand over.

The bottom line is short. SecureGo plus is the consent gate, not the data store. The account list, balances, booked and pending transactions and standing orders are read through Atruvia's Berlin Group XS2A interface, and the practical work is fitting an account-information session around the decoupled approval that lands in this app. That is the route we would take, and the rest of the page is specific about how.

Where the data sits: PSD2, BaFin and the Atruvia XS2A interface

Germany implemented PSD2 early and the access-to-account interface for the cooperative banks is the Berlin Group NextGenPSD2 XS2A standard, operated centrally by Atruvia AG for the whole VR network. Atruvia publishes a production PSD2 API (version 1.3 with errata, per its public swagger) and a separate XS2A test environment; third-party access requires a valid PSD2 TPP certificate. BaFin supervises the licensed providers on that interface. The interface supports the four Berlin Group SCA approaches — redirect, OAuth, embedded and decoupled — and the decoupled approach, piloted and then rolled out across the VR banks (per Atruvia's XS2A release notes, around April 2022), is the one where VR SecureGo plus carries the approval.

Consent has a real lifecycle here. Atruvia's sandbox documentation describes a consent validity of up to 180 days and a frequency-per-day model where multiple unattended account calls inside a five-minute window count once. Those two numbers shape sync cadence, and we treat them as design inputs rather than afterthoughts. This is settled EU and German regulation, not a rule in flux, so the build can rely on it.

What VR SecureGo plus touches versus what the VR Banking backend holds

Routes to a working VR cooperative-bank account feed

Regulated account information via Atruvia Berlin Group XS2A (decoupled SCA)

This is the route we recommend and the one the stack is built for. Reachable: account list, balances, booked and pending transactions, standing orders, with consent valid up to 180 days. Effort is moderate and front-loaded in the consent and SCA handling rather than the data parsing. Durability is high — it is a regulated, versioned interface, not a screen layout. We set up the TPP certificate with you during onboarding and run the build against the Atruvia XS2A sandbox first, then point it at production.

Authorized interface integration of the VR Banking app traffic

Where a field is needed that the account-information scope does not return, we analyse the VR Banking app's own authenticated traffic under your authorization. Reachable: app-specific surfaces beyond the regulated dataset. Durability is lower because a front-end revision can change it, so we add a change-detection check in maintenance that flags a revision as an alert rather than letting it break silently. We use this as a supplement, not the spine.

User-consented credential access and native export

For one-off pulls or fields outside both paths above, a user-consented session or the export VR online banking offers (camt / MT940 / CSV statement downloads, where the institute enables them) can fill a gap. Lowest engineering cost, least suited to a continuous feed. We would reach for it only to close a specific gap, and we would say so plainly rather than dress it up as the main route.

The package we hand over for a VR SecureGo plus / VR Banking build

Everything is tied to the surfaces above, not a generic template:

• An OpenAPI / Swagger specification for the account-information endpoints we wire — consent creation, account list, balances, transaction retrieval, consent status — against the Atruvia XS2A shape.
• A protocol and auth-flow report covering the decoupled-SCA handoff: the consent resource, the authorization sub-resource, the polling of SCA status while the customer confirms in SecureGo plus, and certificate / QWAC handling.
• Runnable source for the key calls in Python and Node.js, including the decoupled-SCA wait loop and consent renewal before the 180-day expiry.
• Automated tests against the Atruvia sandbox, including the pending-then-confirmed and the consent-expired paths.
• Interface documentation, plus compliance and data-retention guidance written for a PSD2 AISP context — consent records, logging, data minimization.

A decoupled-SCA consent call, sketched

Illustrative, in the Berlin Group shape Atruvia implements; exact headers and resource paths are confirmed against the sandbox during the build.

# 1. Create an account-information consent (TPP QWAC + signed request)
POST /v1/consents
  X-Request-ID: 8f2c...­
  PSU-IP-Address: 198.51.100.7
  TPP-Redirect-Preferred: false          # decoupled, not redirect
{
  "access": { "balances": [], "transactions": [] },
  "recurringIndicator": true,
  "validUntil": "2026-11-13",            # <= 180 days, per Atruvia sandbox docs
  "frequencyPerDay": 4
}
-> 201 { "consentId": "VRC-...", "consentStatus": "received",
         "_links": { "startAuthorisation": { "href": ".../authorisations" } } }

# 2. Start authorisation -> bank pushes the approval into VR SecureGo plus
POST /v1/consents/{consentId}/authorisations
-> 201 { "scaStatus": "scaMethodSelected", "chosenScaMethod": "DECOUPLED" }

# 3. Poll while the customer confirms in SecureGo plus (release code / Face ID)
GET  /v1/consents/{consentId}/authorisations/{authId}
-> { "scaStatus": "started" }      # repeat with backoff until:
-> { "scaStatus": "finalised" }    # consent now "valid"

# 4. Read the data the consent now covers
GET  /v1/accounts
GET  /v1/accounts/{resourceId}/transactions?bookingStatus=both&dateFrom=2026-02-13
# 429 / consentInvalid -> renew consent, do not hammer the interface
      

Three integrations teams ask us for

1. Multi-bank dashboard. A money app wants the customer's VR accounts beside accounts elsewhere: create the AIS consent, run the decoupled approval through SecureGo plus, pull the account list, balances and ninety days of transactions, normalize and refresh inside the frequency rule.
2. Nightly reconciliation. An accounting tool ingests booked and pending transactions each night within one 180-day consent, renewing ahead of expiry so the feed never lapses unnoticed.
3. Affordability snapshot. A lender pulls a one-off twelve-month transaction history under a single consent for an income-and-outgoings check, then discards the session.

Engineering specifics we plan around for this stack

These are the things we account for, not hurdles for you to clear:

• The approval leaves the API channel and lands in SecureGo plus as a push. We design the status polling and its timeout around that out-of-band step so a customer who is slow to confirm reads as pending, not error.
• The 180-day consent ceiling and the count-once-per-five-minutes frequency model drive the scheduler. We renew before expiry and pace unattended calls so a sync stays inside the rule instead of tripping it.
• Up to three SecureGo plus devices can be active per customer, and each local Volksbank or Raiffeisenbank has its own Bankleitzahl while sharing one Atruvia interface. We parametrize device state and per-institute routing so one integration covers the network.
• The TPP eIDAS / QWAC certificate is set up with you during onboarding; the build runs against the Atruvia XS2A sandbox before it touches production, so the certificate work and the code mature together.

Screens from the app

Store screenshots, used here to scope the visible surfaces. Select to enlarge.

What was checked, and where it came from

Reviewed in May 2026. We read the official Volksbanken Raiffeisenbanken product page for SecureGo plus and the VR Banking app description for the data the network exposes to customers, then Atruvia's third-party XS2A pages and its published PSD2 swagger for the interface shape, SCA approaches and consent rules, and the Berlin Group NextGenPSD2 material for the standard itself. Sources opened: vr.de — VR SecureGo plus app, Atruvia — third-party interface (XS2A), Atruvia PSD2 API swagger, Berlin Group — NextGenPSD2 downloads.

OpenBanking Studio — integration desk · assessment dated 2026-05-17

The German SCA-app and cooperative-banking neighbourhood

Same-category apps an aggregator covering German retail banking tends to meet. Listed for ecosystem context, not ranked:

• VR Banking app — the cooperative group's primary banking app on the same Atruvia backend; it holds the account list, balances and transaction history that SecureGo plus authorizes access to.
• S-pushTAN — the savings-bank group's push-based release app; the equivalent decoupled approval role over the Sparkasse online-banking backend.
• SpardaSecureGo+ — Sparda-Bank's push approval app, the same SCA function for Sparda online banking.
• Deutsche Bank photoTAN — image-based release for Deutsche Bank accounts; per Deutsche Bank it is being moved toward BestSign for new setups.
• Postbank / Deutsche Bank BestSign — an in-app release procedure that binds SCA into the banking app itself.
• HypoVereinsbank Mobile Banking — UniCredit's German retail app, holding HVB account and card data behind its own SCA flow.
• TARGOBANK Mobile Banking — retail account and card data with app-based authorization.
• DKB / TAN2go — DKB's push-TAN app for its online-banking accounts.
• comdirect photoTAN — comdirect's release app over the Commerzbank-group backend.

Questions integrators ask about VR SecureGo plus

Does VR SecureGo plus itself hold the account balances, or do they live elsewhere?

SecureGo plus holds the device binding, the release-code or biometric credential, and the per-transaction signing queue. Balances, booked and pending transactions, and standing orders sit behind the VR Banking online-banking backend and are read through Atruvia's Berlin Group XS2A interface, with SecureGo plus acting as the decoupled-SCA approval.

How does the consent approval actually reach the user during a sync?

Under the decoupled SCA approach Atruvia rolled out across the VR banks (per its XS2A release notes, around April 2022), the authorization request is pushed into VR SecureGo plus. The user confirms with the release code or Face ID / Touch ID, and the account-information session continues once the bank reports the SCA complete.

One integration for all the local Volksbanken and Raiffeisenbanken, or one per bank?

The cooperative banks share Atruvia's single XS2A interface. We parametrize per-institute routing so a single integration covers the network, with per-bank differences such as the Bankleitzahl and product scope mapped during the build rather than re-coded per bank.

Who supervises this and what certificate does the access path need?

It is PSD2 access under BaFin supervision. The interface requires a valid eIDAS PSD2 role certificate (an AISP or PISP QWAC). We arrange and wire that with you during onboarding, and the build starts against the Atruvia XS2A sandbox before production.

Can you deliver just the account-information read path for VR accounts, without payment initiation?

Yes. Scoping to account information only — account list, balances, transactions and the consent lifecycle — is common and keeps the certificate role and the consent model simpler. You get runnable source for the read path, its automated tests, and the auth-flow report.

A read-path build for the VR cooperative network — consent creation, decoupled-SCA handling, account list, balances and transaction retrieval against the Atruvia XS2A interface — is a one-to-two-week piece of work. You can take it as delivered source code from $300, runnable with its automated tests and auth-flow report, invoiced only after it is in your hands and you have checked it; or call a hosted endpoint we operate and pay per call with nothing upfront. Either way the brief you give us is short: the app name and what you want out of its account data — the certificate, sandbox and compliance setup are arranged with you as part of the work. Start the conversation at /contact.html.