Reaching the BCGE account behind the BCGE Twint app

Every franc BCGE Twint moves is debited or credited straight against a BCGE Privé or current account, with login bound to the customer's BCGE Netbanking access. That single fact decides the whole integration: the records worth syncing — running balance, person-to-person sends and requests, in-store and online payments — sit at the Banque Cantonale de Genève backend, while TWINT is the rail that surfaces them. So the question is not how to read a wallet; it is how to read one Geneva cantonal-bank account through a wallet, under the customer's authorization. That route exists, and as of late 2025 it became materially easier.

The recommendation here is straightforward: build on bLink's Account Information Service as the primary path, because it is the route Swiss banks themselves now sanction for reading private account data, and fall back to authorized analysis of the app's own traffic for anything bLink does not yet expose for this account. Below is what each surface holds, the worked shape of a pull, and exactly what lands in your repository.

What BCGE Twint actually holds

These are the surfaces the app exposes to its own user, named the way the app and BCGE describe them. The integrator value is in the right-hand column — what each becomes once it is normalized and queryable.

The package identifier on the Android build is reported as com.bcge.android.twt on the store listing. Monthly transaction ceilings — BCGE publishes figures in the region of CHF 4,000 person-to-person and CHF 5,000 in shops — bound how much flows, not whether you can read it.

Routes in, and the one we lean on

bLink Account Information Service (primary)

SIX runs bLink as Switzerland's shared open-banking platform, with AIS letting an authorized service user read a customer's balances and transactions after that customer grants consent inside the bank's own e-banking. SIX extended this to private customers in November 2025; more than thirty banks now offer the underlying interface. For BCGE this is the cleanest path: standardized payloads, an explicit consent object, and a contractual footing the bank already supports. Effort is moderate — onboarding to bLink and consent plumbing — and durability is high because it is the sanctioned channel rather than a scraped one.

Authorized protocol analysis (backstop)

Where bLink does not yet expose a given account type, or you need a field the AIS schema omits, we analyze the app's own client-to-server traffic under the account holder's authorization: the Netbanking login and PIN handshake, the session token, and the calls the wallet makes to fetch its transaction list. This reaches anything the app itself shows. It is more sensitive to front-end change, so we treat it as the field-completeness layer behind the AIS spine, not the default.

User-consented credential access (narrow)

For a single-tenant tool — one consenting account, no resale — a consented-credential bridge can be the fastest thing to stand up. It carries the most maintenance per account, so we reserve it for low-volume, internal cases and tell you plainly when it is the wrong shape.

Across these, access onboarding — bLink registration, the consent grant, or a sandbox account — is arranged with you during the engagement; it is part of the work, not a hoop to clear before we begin.

A worked pull

Illustrative shape only — the exact field names and the consent-grant sequence are confirmed against the live interface during the build. It shows the AIS path: exchange the consent reference for a token, then page the account's transactions.

POST /b6/v1/consents/{consentId}/token        # bLink AIS, consent granted in BCGE e-banking
Authorization: Basic <serviceUser:secret>

-> 200 { "access_token": "...", "expires_in": 1800, "scope": "accounts:read transactions:read" }

GET  /b6/v1/accounts/{accountId}/transactions?dateFrom=2026-05-01&page=0
Authorization: Bearer <access_token>

-> 200 {
     "account":     { "iban": "CH.. (BCGE)", "currency": "CHF", "balance": "1842.55" },
     "transactions":[
       { "id":"tx_8841", "bookingDate":"2026-05-14", "amount":"-24.90",
         "channel":"twint_merchant", "counterparty":"Migros Geneve" },
       { "id":"tx_8839", "bookingDate":"2026-05-13", "amount":"+50.00",
         "channel":"twint_p2p", "counterparty":"+41 7x ..." }
     ],
     "_page": { "next": 1, "hasMore": true }
   }

# Handle: token expiry mid-page (re-mint, resume cursor), consent revoked (410 -> stop, surface to user),
#         and the CHF balance string vs. minor-unit normalization.

What lands in your repository

Each item is tied to a real BCGE Twint surface, not a generic checklist:

• An OpenAPI/Swagger spec covering accounts, balance, and the transaction list — the fields above modelled as a stable contract regardless of which route fills them.
• A protocol & auth-flow report: the bLink consent-and-token exchange, and where protocol analysis is used, the Netbanking login / PIN / session-token chain documented step by step.
• Runnable source for the key endpoints in Python or Node.js — token minting, paginated transaction fetch, balance read, consent-expiry handling.
• Automated tests against recorded fixtures so a BCGE or bLink front-end change is caught before it reaches your data.
• A normalizer that turns CHF balance strings and mixed P2P/merchant/Twint+ events into one consistent transaction schema.
• Interface documentation plus consent-record and data-retention guidance fit for the Swiss FADP.

The legal footing, specific to Geneva

Switzerland has no PSD2 and no statutory open-banking mandate; the framework is industry-led, standardized by Swiss FinTech Innovations and operated through SIX bLink, with FINMA as the prudential supervisor rather than an access regulator. For a BCGE customer that makes the dependable basis simple and concrete: the explicit consent the account holder grants inside BCGE e-banking, which is exactly what bLink AIS records. On top sits the revised Federal Act on Data Protection, in force since September 2023, which governs how the pulled records are stored, minimized and deleted. We scope each consent to the narrowest field set that answers your use case, keep the consent and access logs, sign an NDA where the work touches your customers, and design revocation so a withdrawn consent stops the sync cleanly rather than failing silently.

Two things we handle that are particular to this app

First, the BCGE-account boundary. Because the wallet reads one cantonal-bank account rather than a pooled TWINT balance, we model the account as the source of truth and treat P2P, merchant and Twint+ events as typed streams over it — so a refund, a parking charge and a P2P top-up never collapse into one ambiguous "TWINT transaction" row. We map the channel tag on every event during the build.

Second, the consent-refresh window. bLink consents and tokens expire on a fixed clock, and a private-customer consent can be revoked from BCGE e-banking at any time. We design the sync around that lifecycle — re-minting tokens before expiry, detecting a revoked consent and surfacing it — so the integration does not quietly go stale. Where bLink has not yet lit up a given account type, access is arranged with you during onboarding against a consenting account, and we wire a re-validation step into maintenance so a BCGE front-end change is caught early rather than in production.

What a build costs

A typical BCGE Twint build — accounts, balance, transaction list, consent handling, tests — runs a one-to-two-week cycle. Source-code delivery starts at $300: you receive the runnable source, spec and documentation, and you pay after delivery, once it works to your satisfaction. The alternative is the hosted route — we run the endpoints, you call them and pay per call, with nothing upfront. Same data either way; the choice is whether you want to operate the integration or just consume it. Tell us the account scope and what you need from it and we will say which fits. Start the conversation here.

Three ways teams use this

• Personal-finance aggregation. A Swiss budgeting app folds a user's BCGE balance and TWINT history in beside their other bank feeds over bLink, with one consent per account.
• Merchant reconciliation. A Geneva business matches incoming TWINT receipts against its ledger, reading the merchant-payment stream with channel tags intact.
• Internal treasury view. A consenting account holder pipes near-real-time balance and outflow into an internal dashboard, scoped to read-only fields under the FADP.

Interface evidence

Store screenshots of the running app, used to confirm the surfaces named above. Tap to enlarge.

How this was checked

Reviewed in June 2026 against the BCGE TWINT product and terms pages, the SIX bLink AIS documentation and its multibanking-launch release, and the SFTI Common API project notes; app surfaces cross-checked against the Play and App Store listings. Primary sources:

• BCGE TWINT product page
• SIX bLink — Account Information Services docs
• SIX — launch of multibanking for private customers
• SFTI — Common API project

Mapping by the OpenBanking Studio integration desk, June 2026.

Nearby apps in the same data space

Neutral context, useful when a single integration needs to span more than BCGE. Each holds account or payment data a unified feed could include; names are listed for orientation, not ranking.

• TWINT (prepaid) — the shared wallet for customers whose bank has no own-branded TWINT; balance and P2P history without a bound bank account.
• Yuh — Swiss banking app with its own TWINT, holding account, card and investment records.
• Neon — app-based account with card transactions; relies on the prepaid TWINT rather than an own wallet.
• Zak — Bank Cler's mobile account with budgeting pots and transaction history.
• PostFinance TWINT — the same wallet bound to a PostFinance account, mirroring the BCGE structure.
• UBS TWINT — UBS-account-bound wallet with balance and transaction surfaces.
• ZKB TWINT — Zürcher Kantonalbank's cantonal-bank equivalent of this exact pattern.
• Raiffeisen TWINT — Raiffeisen-account wallet, another bank-bound TWINT.
• Revolut — multi-currency account and card data, common in Swiss aggregation alongside a domestic bank.

Questions integrators ask

Does reaching BCGE account data go through TWINT or through BCGE Netbanking?

The wallet authenticates against the customer's BCGE Netbanking access and a BCGE Privé or current account, so the durable data — balances, debits, credits — lives at the Banque Cantonale de Genève backend, not inside TWINT's shared payment rail. We model the integration around the BCGE account boundary, with the TWINT P2P and merchant events read as a transaction stream on top of it.

Is bLink consent available for a private BCGE customer, or only corporate?

SIX opened bLink multibanking to private customers in November 2025, with the consent granted inside the bank's own e-banking. We confirm during onboarding whether BCGE exposes the AIS interface for the specific account type in scope; where it is not yet live for a given account, we build against an authorized, consenting login instead and keep the data shape identical so you can switch later without reworking your code.

How do the TWINT spending limits affect a sync we build?

BCGE publishes monthly ceilings — roughly CHF 4,000 person-to-person and CHF 5,000 in shops per its terms — which cap transaction volume but not data access. We design the polling cadence and pagination around realistic event counts under those ceilings, so a daily or near-real-time sync stays well inside normal usage.

What does a Swiss app mean for the legal basis, given there is no PSD2 here?

Switzerland runs open banking as an industry framework, not a statutory mandate, so the dependable basis is the customer's explicit consent recorded in BCGE e-banking, layered with the revised Federal Act on Data Protection. We deliver the consent records, retention rules and a data-minimized scope so only the fields you need leave the bank.