Wiring BCV TWINT payment activity into a third-party system

BCV TWINT sits on a real bank account, not a closed wallet. The TWINT account is linked directly to the holder’s BCV current or joint account, so most of the data a third-party integrator wants — balance, transaction list, IBAN, signing authority — is BCV data with a TWINT presentation layer on top. The interesting piece is the layer above: per-counterparty P2P sends, merchant charges through TWINT-compatible terminals, the 30-day buy-now-pay-later balance, linked Supercard / Cumulus / Jelmoli numbers, parking sessions with start and end timestamps, donation history. None of that is in a CSV the user can download cleanly; it is what the app paints onto the home screen.

Two things matter for the route. First, BCV was named by SIX as a participant when retail multibanking went live on 25 November 2025 via bLink, so the AIS-style consent flow against BCV-net is a stated channel for the account side. Second, the TWINT-specific surfaces still live behind the TWINT app session itself, so the build pairs the bLink leg with an authorized session integration we set up alongside the customer. That is the spine of the recommendation; everything below is the detail behind it.

What sits in the back end, surface by surface

The two routes we actually use

1. bLink AIS consent against BCV-net (banking side)

SIX’s bLink is the Swiss multibanking hub. SFTI’s Common API working group defines the message shapes; bLink runs the consent, identity and routing layer. BCV is connected to bLink and was named among the participating retail-multibanking institutions at the 25 November 2025 launch. The user authorizes us as the third-party provider, the consent is bound to a BCV-net login, and from then on the account, balance and transactions endpoints answer in JSON. Effort is moderate — most of it is paperwork and the TPP onboarding with SIX. Durability is good, because the contract is industry-standard rather than a private API.

2. Authorized session integration on the TWINT layer

The TWINT-specific data — P2P timelines, parking sessions, loyalty links, voucher and donation history — is rendered by the BCV TWINT app on top of the TWINT backend. With the holder’s written consent and credentials, we run protocol analysis on the app’s traffic, identify the calls behind each surface, and reproduce them in code. Effort is higher than the bLink leg. Durability depends on app updates, which is why a re-validation pass is built into the maintenance contract by default.

3. Native export, where it is the right tool

TWINT exposes an in-app overview of revenues and charges as a downloadable file, per its own FAQ. For one-off projects (an annual tax pull, an audit, a personal-finance snapshot), the export is sometimes the cheapest correct answer and we will say so. It is not appropriate for live syncs.

How the bLink leg looks in code

Pseudo-code, not a finished client — the exact header set is confirmed during onboarding with SIX and refined during the build.

# Illustrative. Real field names confirmed during the build.
# Step 1 — register a consent on bLink for the BCV interface.
POST /v1/consents HTTP/1.1
Host: api.blink.six-group.com
Authorization: Bearer <tpp_app_token>
Content-Type: application/json
{
  "tppId": "OPENBANKING-STUDIO-CH",
  "psuIdType": "BCV_NET_USER",
  "scope": ["accounts", "balances", "transactions"],
  "validUntil": "2026-08-29",
  "frequencyPerDay": 4
}
=> 201 { "consentId": "c_abc123", "status": "received",
        "scaRedirect": "https://blink.bcv.ch/oauth2/authorize?..." }

# Step 2 — PSU completes BCV-net strong customer auth at the redirect.
# bLink returns an access token bound to the consent.

# Step 3 — paginate the transaction list.
GET /v1/accounts/{iban}/transactions
    ?dateFrom=2026-04-01&dateTo=2026-05-29&limit=200
Authorization: Bearer <consent_access_token>
X-Consent-Id: c_abc123

=> 200 {
  "transactions": [
    { "bookingDate": "2026-05-12", "valueDate": "2026-05-12",
      "amount": { "value": -38.50, "currency": "CHF" },
      "remittanceInformation": "TWINT - boulangerie X",
      "creditorName": "Boulangerie X SARL", "endToEndId": "TW7723..." }
  ],
  "_links": { "next": "/v1/accounts/CH..../transactions?cursor=..." }
}

# Step 4 — the TWINT-layer client (separate module) decorates each TWINT-rail
# transaction with its counterparty TWINT ID, channel and refund pointer.

What ships at the end of the cycle

For a typical BCV TWINT build, the package is concrete. An OpenAPI 3.1 specification for the endpoints we expose; the runnable client source in Python and Node.js, split into a bLink module and a twint module so either can be used on its own; a written auth-flow report covering the bLink TPP onboarding and the TWINT session chain; a normalized schema that maps both feeds into a single account-and-transactions object so downstream code does not have to care where each row came from; integration tests against a recorded consent; and an interface document for the engineering team on the other side. CHF amounts, value dates and TWINT identifiers are preserved end to end.

Build notes the engineering desk wants flagged

The TWINT layer is shared infrastructure. The BCV-branded app, the ZKB-branded app, the PostFinance-branded app and the others sit on the same TWINT rail, so the P2P and merchant message shapes look similar across them; we hold a single normalized model for that rail and slot BCV-net in as the funding feed for this build. That keeps the bank-specific work narrow and lets a client extend later to a second cantonal partner without rewriting the TWINT layer.

Consent windows are real and we plan the sync around them. bLink consents carry a validity window and a per-day frequency cap; we schedule the pulls under that cap and surface a re-consent prompt on the client side a week before expiry, so the integration never silently dries up. Anything reached through the TWINT app session is more sensitive to UI updates than the bLink endpoints, so we wire a recorded canary call into the test suite — if a payload shape shifts after an app release, the canary fails the build before production traffic does. Sessions, consent IDs and PSU identifiers are kept in the customer’s own secret store; we do not retain them on our side after handover unless the pay-per-call hosting model is being used, in which case the retention scope is named in the agreement.

Mobile-number rotation is a small but real edge. BCV documents a procedure for moving a TWINT account to a new mobile number that preserves transaction history, customer cards and automatic payments; the inverse — deleting the account — wipes history, cards, coupons and badges. Any sync we build keeps a local audit trail so a rotation event on the user side does not look like a data loss event on the integration side.

Consent and the Swiss frame

Switzerland does not have a PSD2-style obligation. Open banking here is industry-led. The standards come from Swiss Fintech Innovations (SFTI) and its Common API working group; SIX’s bLink is the infrastructure they coordinate on; the Swiss Bankers Association co-signed the memorandum of understanding in 2023. FINMA oversees the bank itself rather than the API standard. For personal data, the relevant rule is the revised Swiss Federal Act on Data Protection (revFADP), in force since September 2023, which is the regime we contract under for any data the integration touches.

Operationally that means: explicit user consent on the bLink side, captured with the consent ID and the validity window; a second written consent for anything reached through the TWINT app session itself; data minimization scoped to the surfaces the project actually needs; an NDA where the integrating party requires one; and a logged audit trail so the BCV holder can show a regulator who pulled what and when. None of this is a wall the customer has to clear before we start — the access setup is part of the engagement and we run it with you.

Where this sits in the Swiss app landscape

The same TWINT rail surfaces inside other cantonal and national bank apps, and there is a wider Swiss banking-app neighbourhood around it. Names worth recognizing for a multibank build:

• ZKB TWINT — the Zürcher Kantonalbank-branded TWINT, same payment rail with ZKB account data on the funding side.
• PostFinance TWINT — PostFinance’s TWINT front, funded from a PostFinance account.
• UBS TWINT — the UBS branded TWINT app for UBS retail clients.
• Raiffeisen TWINT — Raiffeisen Switzerland’s TWINT distribution to its members.
• Migros Bank TWINT — Migros Bank’s TWINT front; relevant when integrating with the Migros loyalty side as well.
• Prepaid TWINT — the bank-agnostic prepaid TWINT for users without a participating bank account; a thinner data surface, no account ledger behind it.
• Yuh — the Swissquote / PostFinance joint banking app, with its own multibank features.
• Neon — Swiss neobank running on a Hypothekarbank Lenzburg core; a frequent counterparty in P2P traffic.
• Revolut — international fintech that issues Swiss IBANs, sits next to BCV TWINT in many users’ wallets.
• ZKB Mobile Banking — ZKB’s main banking app, often paired with ZKB TWINT and sharing the same bLink interface.

Sources behind this write-up

This page is one engineer’s notes from reading public material. The primary references are: the BCV TWINT product page on twint.ch for the app’s feature set; the BCV bLink page on bcv.ch for BCV’s position on the SIX bLink platform; the SIX Group multibanking launch release of 25 November 2025 for the named participants and scope of the retail launch; and the BCV TWINT Play Store listing for the live in-app feature list. Where a fact was not in those sources, the page says so.

Mapping last walked through 2026-05-29 by the OpenBanking Studio integration desk — Sebastian Krenz.

Common questions from integrators

What does BCV TWINT actually hold server-side that a third party would want?

Two streams sit behind the app. The current or joint account at BCV, with its IBAN-level balance, transaction list and signing authority — that is the banking surface. Above it, the TWINT layer: per-counterparty P2P sends and receives, in-store and online merchant charges, linked credit-card payments, the buy-now-pay-later balance, parking sessions with start and end timing, linked loyalty card numbers (Supercard, Cumulus, Jelmoli per the app description), and donations to the participating charities.

Does the November 2025 bLink multibanking launch change what is reachable here?

Yes — and it is the route we lean on for the BCV-side surface. SIX named Banque Cantonale Vaudoise among the participating institutions when retail multibanking went live on 25 November 2025, so an AIS-style consent flow against BCV-net is a stated channel. The TWINT-specific data (parking sessions, loyalty links, P2P history) sits behind the TWINT app session itself and is reached through a separate authorized integration we build alongside it.

Can a build be scoped to one TWINT surface, like parking or P2P, rather than the whole app?

Yes. We scope per surface. A parking-only build pulls just the TWINT parking sessions and their refund records; a P2P-only build pulls send and receive history with the counterparty TWINT IDs and timestamps. The auth chain and access setup are arranged with you during onboarding, so the engagement stays focused on the surface you actually need rather than re-mapping the whole app.

Source-code delivery for this build starts at $300 and is paid after delivery, once you have run the code and you are satisfied with what arrived; you get the runnable Python and Node modules, the OpenAPI 3.1 spec, the auth-flow notes, the tests, and the interface documentation. The hosted alternative routes your calls through our endpoint and bills per call, with no upfront fee. Cycle time is 1–2 weeks either way. Send the angle you actually need at /contact.html and we’ll come back with a delivery plan.