VR SecureGo plus API integration (PSD2 / FinTS / OpenBanking)

Create AIS consent (XS2A, Berlin Group)

POST /v1/consents
PSU-IP-Address: 198.51.100.7
TPP-Redirect-URI: https://yourapp.example/cb
X-Request-ID: 5b8b3f4d-...

{
  "access": {
    "balances": [{"iban": "DE02..."}],
    "transactions": [{"iban": "DE02..."}]
  },
  "recurringIndicator": true,
  "validUntil": "2026-08-08",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

201 Created
{
  "consentStatus": "received",
  "consentId": "c-7f2e...",
  "_links": {
    "scaRedirect": {
      "href": "https://xs2a.atruvia.de/sca/c-7f2e..."
    }
  }
}
# User opens scaRedirect, approves in VR SecureGo plus.

Pull a 30-day statement (Python)

import requests, datetime as dt

H = {
  "Consent-ID": CONSENT_ID,
  "X-Request-ID": "9e1c...",
  "PSU-IP-Address": "198.51.100.7",
  "Authorization": f"Bearer {ACCESS_TOKEN}",
}
params = {
  "dateFrom": (dt.date.today() - dt.timedelta(days=30)).isoformat(),
  "dateTo":   dt.date.today().isoformat(),
  "bookingStatus": "both",
}
r = requests.get(
  f"https://xs2a.example/v1/accounts/{ACCOUNT_RESID}/transactions",
  headers=H, params=params, timeout=30,
)
r.raise_for_status()
booked = r.json()["transactions"]["booked"]
for t in booked:
    print(t["bookingDate"], t["transactionAmount"]["amount"],
          t.get("creditorName") or t.get("debtorName"),
          t.get("endToEndId"))

SCA push webhook (Node.js)

// POST /webhooks/sca from our gateway
app.post('/webhooks/sca', express.json(), (req, res) => {
  const sig = req.header('X-OFL-Signature');
  if (!verifyHmac(sig, req.rawBody, SECRET)) {
    return res.status(401).end();
  }
  const { consentId, paymentId, decision,
          deviceId, decidedAt } = req.body;
  // decision: APPROVED | REJECTED | EXPIRED
  ledger.recordScaEvent({
    consentId, paymentId, decision,
    deviceId, decidedAt,
  });
  res.status(204).end();
});

Regulatory framing

Every flow we ship is designed around the EU's Second Payment Services Directive (PSD2) and the European Banking Authority's RTS on Strong Customer Authentication. The interface against the cooperative core is the regulated XS2A endpoint operated by Atruvia for the Volksbanken Raiffeisenbanken network. National supervision sits with BaFin and the Deutsche Bundesbank, and personal data handling is governed by the GDPR plus the German BDSG.

What we never do

• We do not store the user's release code or biometric template.
• We do not bypass the SCA push — every consent or payment crosses VR SecureGo plus (or the user's chosen Sm@rt-TAN / chipTAN fallback).
• We do not scrape screens that a documented PSD2 endpoint already covers; scraping is reserved for back-office data with explicit written authorization.
• We support data-minimization: only the IBANs, fields, and date ranges asked for in the consent are returned to the client.

Deliverables checklist

• OpenAPI 3.1 specification covering accounts, balances, transactions, payments, SCA
• Protocol & auth flow report (XS2A consent dance, FinTS dialog, optional eIDAS QWAC notes)
• Runnable source for AIS and PIS clients in Python and Node.js, plus a Go statement-export worker
• Postman / Bruno collection with sandbox + production environments
• Automated tests against a synthetic ASPSP plus a sample Atruvia sandbox tenant
• Compliance guidance pack: PSD2 SCA notes, GDPR data-minimization checklist, sample consent text

Engagement workflow

1. Scope confirmation: which Volksbanken, which data, AIS only or AIS + PIS.
2. Protocol analysis & API design (2–5 business days).
3. Build & internal validation against sandbox (3–8 business days).
4. Docs, samples, test cases (1–2 business days).
5. First delivery typically lands in 5–15 business days; eIDAS certificate procurement and BaFin-side approvals can extend that.

About OpenFinance Lab

We are an independent technical studio focused on mobile-app protocol analysis and OpenData / OpenFinance / OpenBanking integration. Engineers on the team have shipped production code for German cooperative banks, Sparkassen, neobanks, and a handful of pan-EU PSPs, so we know the difference between the documented Berlin Group spec and what a specific Volksbank actually returns at 23:59 on a Saturday.

• DACH banking, payments, and brokerage stacks
• PSD2/XS2A, FinTS/HBCI, EBICS, SWIFT MT and ISO 20022 fluency
• Custom Python / Node.js / Go SDKs and reproducible test harnesses
• End-to-end pipeline: protocol analysis → build → validation → compliance hand-off
• Source code delivery from $300 — runnable code and full documentation; pay after delivery upon satisfaction
• Pay-per-call hosted API — no upfront fee, ideal for usage-based pricing

Contact

For quotes, NDA review, or to send us your target requirements (which Volksbanken, which data fields, which downstream tools), open our contact page below. We typically reply within one business day.

Contact page

FAQ

Is VR SecureGo plus integration legal under German and EU rules?

Can I export transaction history from VR cooperative bank accounts via API?

How long does a typical delivery take?

How do you handle compliance and the SCA factor?

Common modules

• Consent creation, status, refresh, and revoke
• Account list, balances, booked & pending transactions
• SEPA credit transfer and SEPA Instant payment initiation
• Standing-order management and SEPA mandate sync
• Credit-card transaction read with MCC and authorization metadata
• SCA push webhook for downstream audit and fraud tooling
• FinTS / HBCI fallback for back-office tools that need MT940