Pulling BCV-net data through the Swiss bLink AIS rails

BCV — Banque Cantonale Vaudoise, the cantonal bank of Vaud — uses the BCV Mobile app as the consumer front to its BCV-net portal, and that portal already carries the data an integrator usually wants: account balances, individual booking lines, debit and credit card history, BVR / QR-bill / CCP / SIC payment instructions and securities-account positions. BCV is also a published participant on SIX bLink, which means there is a Swiss-standard Account Information rail you can lean on for the regulated path. That is the spine we usually build around for this bank, with a documented protocol path slotted underneath for the surfaces bLink does not yet cover.

Authorized routes to the data behind BCV Mobile

Three routes apply here in practice, and one fallback. Each is something we set up with the client during onboarding — access, written authorization, sandbox or consenting account are arranged together as part of the engagement.

1) SIX bLink — the Swiss AIS spine

bLink is the SIX-operated open-banking platform that the Swiss financial center is rallying around. Per its public documentation and participant lists, BCV is one of the banks exposing Account Information Services through bLink, alongside ZKB, PostFinance, UBS, Raiffeisen, BEKB, SGKB, Valiant and Lombard Odier. Standardized scopes, consent management, OAuth2-style token flow, ISO 20022-aligned payloads. This is the cleanest spine for a long-lived BCV integration, and for retail multibanking — which SIX confirmed went live for private clients in late 2025 — it is the route that does not break when the bank refreshes its front end. Effort is moderate, durability is high, and onboarding goes through SIX as a Third-Party Provider.

2) Authorized BCV-net interface integration

For surfaces bLink does not yet cover for BCV — securities-account performance views, push-event subscriptions, fine-grained card data, branch and rate look-ups the app surfaces — we do a documented protocol analysis of the BCV-net session and BCV Mobile traffic under a consenting end-user's written authorization. Compliance-first: nothing about defeating authentication, nothing about probing rate limits. The output is an OAuth / token / cookie-chain map for the surfaces the client actually needs, plus the runnable client. Durability sits below bLink because front-end revs need a quick re-check; we plan that in.

3) User-consented credential access

Where bLink onboarding is not viable in the project's timeline, the integration logs into BCV-net on the consenting user's behalf, with consent scope held to exactly what the brief needs. Useful for one-shot account-aggregation pilots and for treasurers running automation against their own corporate accounts.

4) Native export, as fallback

BCV-net offers statement export in the usual Swiss formats — camt.052/053/054, PDF, CSV. If the use case is bookkeeping reconciliation and not real-time, this is the cheapest path and pairs well with bLink for the live signals.

Where the schedule allows route 1, that is the path we build on; routes 2 and 3 slot in underneath where the bLink coverage does not yet match the brief. Most BCV builds we scope end up as a bLink-AIS feed plus a thin protocol-analysis layer for two or three surfaces — that is what we would recommend reading first.

Available data domains

Shape of a call: BCV via bLink AIS

The snippet below sketches the consent-then-fetch path for an account-information call against BCV through bLink. Exact endpoints, scopes and headers are confirmed against the bank's live bLink configuration during the build — bLink mediates the actual scheme and BCV publishes its product set to SIX.

# Illustrative — BCV Account Information via SIX bLink
# Real endpoint paths and headers are pinned during onboarding.

# 1) Exchange the consent grant for an access token
POST /oauth2/token
Host: api.blink.six-group.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=<consent_code>
&redirect_uri=https://your.app/callback
&client_id=<TPP_client_id>

# 200 OK
# { "access_token": "...", "expires_in": 1800,
#   "refresh_token": "...", "scope": "ais:bcv:read" }

# 2) Pull the booking lines for a BCV-net account
GET /v1/accounts/{accountId}/transactions?dateFrom=2026-05-01
Authorization: Bearer <access_token>
X-PSU-IP-Address: 198.51.100.7
X-Request-ID: 7d4e-...

# 200 OK
# {
#   "account": { "iban": "CH** 0076 7000 ... ", "currency": "CHF" },
#   "transactions": [
#     {
#       "transactionId": "txn-2026-05-12-...",
#       "bookingDate": "2026-05-12",
#       "valueDate":   "2026-05-13",
#       "amount":      { "currency": "CHF", "value": "-148.55" },
#       "remittanceInformation": "QR-Rechnung Ref 2103 6789 4...",
#       "creditorAccount":  { "iban": "CH93 ... " },
#       "bankTransactionCode": "PMNT-ICDT-AUTT"
#     }
#   ],
#   "_links": { "next": "..." }
# }

# Notes:
# - Consent must be re-confirmed at the bLink-defined cadence
#   (Strong Customer Authentication re-up). The client handles
#   refresh and surfaces a re-consent prompt before expiry.
# - bankTransactionCode follows the ISO 20022 code list, which
#   the QR-bill standard requires for Swiss payments.
      

What ships at the end of a BCV build

The deliverable is a runnable bundle, not a slide deck. For BCV Mobile specifically, that means an OpenAPI 3.1 spec describing the surfaces in the brief — accounts, transactions, cards, payment-initiation, securities positions, reference data; a Python client (with a Node.js variant on request) covering the bLink AIS path and the BCV-net protocol path where needed; a protocol and auth-flow report that documents the OAuth grant on bLink and the token / cookie chain on the BCV-net session; a pytest suite that exercises happy path, consent expiry, idempotency on payment-initiation and the credit-card-lag edge case; a normalized transaction schema so debit and credit card histories arrive in one shape; and the interface documentation a downstream team needs to keep the integration running without reading the source. Compliance and retention guidance is shipped with it — what is logged, what is kept, what is purged.

Engineering specifics we work through on a BCV build

• Consent-refresh schedule. The Swiss AIS rails impose a Strong Customer Authentication re-up cadence; we design the sync around that window so the data feed does not silently expire on a quiet weekend. Re-consent prompts are surfaced in the client app, not buried.
• Card-feed split. Inside BCV-net the Cards module is a separate view from the main statement, and credit-card postings settle later than debit. We normalize the two into a single transaction schema with a card_type discriminator and preserve the original posting time, so downstream systems get one feed and can still tell debit from credit.
• QR-bill reuse across Swiss banks. QR-bill payloads follow the SIX-published Swiss Payment Standards and become an ISO 20022 pain.001 instruction. Our payment-initiation code is bank-agnostic at the parse layer — only the scopes and consent flow change between BCV, ZKB or PostFinance — so a customer running multi-bank payments gets one parser, not three.
• Securities-account coverage. Securities positions are not yet first-class on every participant's bLink surface. Where the brief needs portfolio mirroring, we wire the BCV securities view through the authorized portal route in parallel with the AIS feed and merge them at the schema layer; the client sees one positions endpoint.
• BCV-net front-end revs. The portal occasionally gets a theme refresh or new module layout. For the protocol-analysis path we book a quick re-check into the maintenance window up front rather than discovering it on a Friday, and the bLink path absorbs the rev automatically.

Swiss consent posture and what governs the data here

BCV is a FINMA-supervised bank, and Swiss customer-secrecy expectations sit on top of the Federal Act on Data Protection (FADP, revised 2023). Switzerland does not have a PSD2 equivalent — there is no regulatory mandate forcing the bank to open its interfaces. Open banking here is market-driven: SFTI publishes the Common API specification, SIX runs the bLink platform that productizes Account Information and Payment Submission, and banks join on commercial terms. For BCV that means the dependable basis for an integration is the consent of the BCV-net account holder, formalized through bLink's Third-Party Provider onboarding for the AIS rail or through written authorization for the protocol-analysis path. Consents are scoped, time-limited, revocable from inside BCV-net, and logged on our side against the engagement.

Build scenarios we have scoped on similar Swiss bank apps

• SME accounting feed. Vaud-based SME on Bexio or Abacus needs daily BCV booking lines and end-of-day balance into the bookkeeping ledger. bLink AIS feed, camt.053 nightly as the safety net, no protocol path needed. Two-week build.
• Treasury multibanking. A corporate runs accounts at BCV plus one or two other Swiss banks (typically ZKB or PostFinance) and wants one cash-position view plus QR-bill payment-initiation. bLink AIS + PSS across all banks; one parser for QR-bills; one dashboard.
• Wealth-tech mirror. Fintech mirrors the BCV securities-account view into a portfolio analytics product. AIS for cash, authorized portal route for positions and performance, merged at the schema layer.
• Expense automation. A finance app pulls debit + credit card transactions across the BCV cardholders in a company, enriches the merchant strings and pushes them into an expense workflow. Card-feed split is handled inside the normalized schema.

App surfaces — interface evidence

What BCV Mobile shows on the consumer side, captured from the public Play Store listing. These are the screens whose underlying data the integration ends up reaching.

Mapping notes for this page

For this brief we worked off the BCV Mobile Play Store listing (package ch.bcv.mobile.android, per the store URL) and BCV's own English-language site, then cross-checked the Swiss open-banking picture against the SIX bLink documentation and SFTI's Common API project page. The participant list confirming BCV's presence on bLink is the most load-bearing fact behind the route recommendation. Mapping reviewed May 2026 by the OpenBanking Studio integration desk.

• BCV — BCV-net e-banking (bank's own page)
• SIX bLink — Account Information Services documentation
• SFTI — Common API working group
• Wikipedia — Banque Cantonale Vaudoise

Other Swiss banking apps with similar data

A unified Swiss-bank integration usually touches a handful of these. Listed neutrally — naming, not ranking.

• ZKB Mobile Banking — Zürcher Kantonalbank; the largest cantonal bank, also a bLink participant, similar BCV-net-style portal pattern.
• PostFinance App — the Swiss postal bank's consumer app; heavy on retail payments and a bLink participant for AIS.
• UBS Mobile Banking — global universal bank with strong wealth surfaces; bLink-active and the public face of bLink multibanking.
• Raiffeisen e-banking — cooperative network; bLink participant; the SME footprint overlaps heavily with BCV's corporate customers.
• BCBE Mobile Banking — Berner Kantonalbank; a peer cantonal bank with comparable BCV-net-style portal and AIS posture.
• TKB Mobile — Thurgauer Kantonalbank; cantonal peer with strong digital ranking in recent IFZ studies.
• SGKB Mobile Banking — St. Galler Kantonalbank; bLink participant for account information.
• Valiant Mobile Banking — regional bank, cantonal-bank-adjacent footprint, on bLink.
• Migros Bank Mobile — retail banking arm of Migros; comparable QR-bill and SIC payment data behind the app.
• Yuh — joint PostFinance / Swissquote mobile offering; different shape (broker-light) but the same Swiss payment plumbing underneath.

Questions integrators ask about BCV Mobile

Is BCV a confirmed participant on the Swiss bLink open-banking platform?

Yes. BCV appears in published SIX bLink participant lists alongside ZKB, PostFinance, UBS, Raiffeisen, BEKB, SGKB, Valiant and Lombard Odier. The exact set of bLink products active for BCV — Account Information, Payment Submission, wealth surfaces — is confirmed bank-by-bank during onboarding.

Can the integration parse QR-bills the same way the BCV Mobile app does when a user scans one?

QR-bill payloads follow the SIX-published Swiss Payment Standards and map to an ISO 20022 pain.001 instruction. Our payment-initiation code parses the QR text, fills the same fields BCV Mobile would, and pushes the instruction through either the bLink PSS rail or the BCV-net session, depending on the route chosen for the build.

How do you handle BCV's FINMA-supervised customer-secrecy posture during a build?

Builds run under written authorization, against a consenting account where AIS is not in play, with engagement-scoped logs and retention. Customer-identifying data does not leave the build environment without the client's sign-off; NDAs are in place by default.

BCV Mobile shows debit and credit card history in separate places — how is that exposed downstream?

Inside BCV-net the Cards module is split from the main statement booking lines, and credit-card detail lags relative to debit. We normalize both feeds into one transaction schema, with a card_type discriminator and the original posting time preserved, so downstream systems do not have to learn the BCV-net split.

USD 300 covers the runnable source bundle for one BCV Mobile build — OpenAPI spec, Python or Node.js client for the surfaces in scope, automated tests against a consenting BCV-net account, and the interface document — and you pay only after delivery, once you have looked at the result. The other option is the hosted endpoint: you call our API and pay per call, no upfront fee. Either way the cycle runs one to two weeks. Send us the BCV-net surfaces you actually need and we will scope it from there.

Mapping reviewed 2026-05-30 · BCV bLink participation rechecked against the SIX participant list