Banque Transatlantique sits inside CIC, which itself sits inside Crédit Mutuel Alliance Fédérale, and the parent group already publishes a regulated PSD2 AIS surface based on the STET standard, accessible to AISPs registered with the ACPR. That fixes most of the route. The cash side of the app — accounts, balances, booked and pending movements, single-credit transfer initiation — is reachable through that regulated channel under a customer consent. Everything else the app shows (the Bourse tile with Euronext orders, the Assurance and Santé contracts, the secure-message channel with the private banker, RIB/IBAN PDFs, card opposition) sits outside the AIS perimeter and is reached through authorized interface integration against the customer's own session. We deliver both behind a single normalized API.
The authorized rails into a Banque Transatlantique customer area
Route A — STET PSD2 AIS through the CIC / Crédit Mutuel developer portal
Reachable: payment accounts (current and sub-accounts), balances, booked and pending movements, card-based balance checks. Effort: low to medium. The STET specification is stable and the CIC and Crédit Mutuel portals expose an OAuth 2.0 authorization-code flow with the standard /accounts, /accounts/{id}/transactions and /accounts/{id}/balances endpoints. Durability: high — this is a regulated obligation under DSP2. Studio side: we handle the AISP registration paperwork with the customer (or work under the customer's own ACPR registration), build against the CIC sandbox, then promote to live once consent is collected from the Banque Transatlantique end customer through the standard Filbanque redirect.
Route B — Authorized interface integration for the surfaces AIS does not touch
Reachable: the Euronext securities portfolio, order placement and follow-up, Assurance contracts and claim status, Santé reimbursements and simulators, RIB/IBAN PDFs, secure-message inbox with the private banker, "Je voyage" toggle, transaction-search results. Effort: medium — we lift the request/response shape of the in-app calls under the customer's authorization (their own credentials, their own consent, no SCA bypass), version-lock to the observed protocol, and add a sentinel job that detects layout drift. Durability: medium; we re-validate the contract on each app release and during scheduled maintenance.
Route C — User-consented credential session for one-shot pulls
Reachable: anything visible to a logged-in user, in a single supervised session. Effort: low for one-off extractions, higher for sustained syncs. Use case: an audit, a one-time portfolio export, a wealth advisor migrating a client book. We pair this with explicit revocable consent and the standard data-minimization terms.
Route D — Native export, where the app already offers one
RIB/IBAN PDFs and statement PDFs come straight out of the app. Useful as a fallback for clients who want a documentary trail and not a live feed; we wire it as a periodic job and OCR the PDFs into the same normalized model.
Our default recommendation on this bank. Use Route A as the spine for cash, then layer Route B for Bourse, Assurance and Santé and bind both into one schema. Route C only when the customer is not eligible for AIS (some corporate or fiduciary accounts at the bank). Route D as the documentary backup the audit team usually asks for.
What the Banque Transatlantique customer space actually holds
| Domain | Where in the app | Granularity | What an integrator does with it |
|---|---|---|---|
| Cash accounts | Comptes home tile | Per-account balance, booked and pending movements, currency where applicable | P&L feeds, reconciliation, expense categorization, cash forecasting |
| SCT transfers | Virements | Initiation between own accounts and to registered beneficiaries; transfer history; beneficiary book | Payment ops, payroll reconciliation, account-to-account orchestration |
| Bank cards | Carte section | Block/unblock, cap removal ("décapage"), per-card movements | Card lifecycle automation, fraud-signal feed, expense controls |
| Beneficiaries, RIB, IBAN | Coordonnées bancaires | Downloadable PDF plus structured IBAN/BIC; add-beneficiary flow | Vendor onboarding, supplier credentials, account-validation gates |
| Securities portfolio | Bourse / Accueil Bourse | Holdings, open and historical orders, Euronext quotes and CAC40 reference, fund selection lists | Wealth dashboards, tax-pack preparation, trading workflow |
| Assurance contracts | Assurance | Contracts list, claim declaration and status, quote simulation for auto and home | Document retrieval, claim triage, broker dashboards |
| Santé | Santé tile | Reimbursement history, simulator for specific medical acts, claim declaration | Health-finance dashboards, reimbursement reconciliation |
| Document vault & secure messaging | Documents section and the private-banker secure channel | Statements, contracts, advice notes; thread-level message metadata | Regulatory archival, document workflow, advisor handover |
| Travel notice | "Je voyage" toggle | Event-driven flag with destination and dates | Risk monitoring, fraud-system signalling |
DSP2, the ACPR, and the consent that backs the read
France implements PSD2 ("DSP2" locally) under the supervision of the Autorité de Contrôle Prudentiel et de Résolution, attached to the Banque de France. To act as an Account Information Service Provider against Banque Transatlantique cash accounts, an AISP is registered with the ACPR or operates under a passport from another EEA regulator. French banks have largely standardized on STET rather than the Berlin Group, and Crédit Mutuel Alliance Fédérale — the parent group here — publishes its PSD2 endpoints accordingly.
Consent is per-customer, per-account list, time-boxed. The current EBA framework, transposed via the ACPR, sets the SCA renewal cycle for AIS access at 180 days, with the Banque Transatlantique customer re-confirming through Mobile Confirmation. We treat that 180-day clock as a first-class object in the pipeline — countdown, refresh job, fallback to a re-consent flow — rather than letting it expire silently. For the Bourse, Assurance and Santé surfaces, the basis is the customer's own authorization to act on their behalf, recorded with an audit trail and an NDA where the customer is itself a regulated entity. GDPR data-minimization applies throughout: we pull only the fields the integrator's use case requires.
On the wire — a walk through the AIS handshake
The STET PSD2 spec used by the CIC group is on v1.4.2 in the live portal and v2.x on the public spec page. The shape below reflects what a build sees on day one; exact paths get confirmed during the build against the CIC sandbox.
import requests, uuid
CIC_OAUTH_BASE = "https://oauth2-apiii.e-i.com/cic" # CIC AIS gateway
CIC_API_BASE = "https://oauth2-apiii.e-i.com/cic/stet/psd2/v1.4.2"
# 1) AISP-side OAuth 2.0 authorization-code exchange.
# The Banque Transatlantique customer has already consented in the
# Filbanque redirect; we now swap the code for an access token.
auth = requests.post(
f"{CIC_OAUTH_BASE}/oauth/token",
auth=(CLIENT_ID, CLIENT_SECRET), # AISP creds, issued at onboarding
data={
"grant_type": "authorization_code",
"code": authz_code,
"redirect_uri": REDIRECT_URI,
},
)
access_token = auth.json()["access_token"]
consent_id = auth.json().get("consent_id") # carried for downstream calls
# 2) List the PSU's payment accounts visible under the consent.
accounts = requests.get(
f"{CIC_API_BASE}/accounts",
headers={
"Authorization": f"Bearer {access_token}",
"Consent-ID": consent_id,
"PSU-IP-Address": psu_ip,
"X-Request-ID": str(uuid.uuid4()),
},
).json()
# 3) For each account, pull the booked + pending movements.
for acc in accounts["accounts"]:
txns = requests.get(
f"{CIC_API_BASE}/accounts/{acc['resourceId']}/transactions",
headers={"Authorization": f"Bearer {access_token}",
"Consent-ID": consent_id},
params={"dateFrom": "2026-04-01", "dateTo": "2026-05-29"},
).json()
# txns["transactions"]["booked"] - confirmed entries
# txns["transactions"]["pending"] - pending entries
# NB: Bourse orders, Assurance contracts and Santé reimbursements are
# NOT exposed on this channel; they come from Route B and are merged
# into the same normalized model on our side.
Error handling worth wiring in early: 401 on an expired consent (re-consent flow), 429 on the per-PSU rate ceiling the portals enforce, and HTTP 503 windows during the CIC group's weekly maintenance slot.
The shape of the handover
For Banque Transatlantique the package usually contains:
- An OpenAPI 3.1 specification that fronts both rails — the STET AIS calls and the interface-integration endpoints for Bourse, Assurance, Santé, secure messaging and document download — under one resource model.
- A protocol & auth-flow report: the OAuth 2.0 authorization-code dance against the CIC portal, the Filbanque login flow, the Mobile Confirmation SCA path, the secure-message ciphering as observed, the consent-renewal countdown.
- Runnable Python and Node.js source for the core endpoints — accounts, transactions, balances, beneficiary list, SCT initiation, securities holdings and orders, contract retrieval, reimbursement history.
- Automated tests: contract tests against the CIC sandbox for the AIS calls, replay tests against recorded sessions for the interface track.
- Interface documentation an integrator can actually read, with the SCA quirks and the renewal cycle written out.
- Compliance and data-retention guidance under DSP2 and GDPR, including the audit-log schema and the deletion path on revocation.
Things we plan for on this build
The split between AIS and not-AIS is the real design choice. The Bourse, Assurance and Santé tiles are most of what makes Banque Transatlantique a private-bank app, and none of them are in the PSD2 perimeter. We design the data model so the integrator does not have to know which surface a field came from — one normalized account graph, one normalized contract graph, one event stream — and we keep the rails independent under the hood so that an outage on one does not stall the other.
The consent clock is wired into the scheduler, not bolted on the side. Mobile Confirmation refreshes the AIS consent every 180 days; we surface that timestamp to the integrator, schedule a refresh job ahead of it, and degrade gracefully (last-known good data, clear "consent expired" signal) rather than producing silent gaps.
Group ambiguity gets resolved up front. The CIC group serves several brands through related portals — CIC itself, Crédit Mutuel, Banque Transatlantique, Banque de Luxembourg — and a careless build can request scopes against the wrong subsidiary's realm. We pin the realm to the actual customer entity and we re-pin on each account that lands in the consent.
Mobile UI churn is treated as expected, not as breakage. The bank refreshes the customer area at a steady cadence; on the interface track we wire a daily contract-check that surfaces drift before the integrator's pipeline sees a 500. Maintenance covers it; the integrator does not have to babysit.
Three jobs this integration actually does
Family-office reporting across Banque Transatlantique and a non-French bank. AIS pulls the cash and movements; Route B pulls the Bourse holdings, the Assurance valuations and the Santé balance. Both feed the family office's portfolio system on a nightly cycle, with the consent-expiry timer wired into the office's renewal calendar.
Expat onboarding for a French-national-abroad client. The customer signs once, we pull the RIB/IBAN PDFs and account list for KYC, then a periodic AIS read keeps the balance and transaction view up to date for the destination-country accounting system.
Tax-pack preparation for the Bourse activity. Once a year, a one-shot extraction of the full year's orders, dividends and corporate-action notices from the Bourse surface, formatted to the integrator's IFU template — Route C with a supervised session, no ongoing data residency.
Keeping the feed fresh
The CIC group runs a weekly maintenance window; AIS calls return 503 through it. We schedule reads around it and expose a "next planned outage" hint to the integrator. The interface track is checked against a recorded golden session on each app version; drift triggers a maintenance ticket the same day the new version ships. For the consent itself we keep a one-record-per-PSU consent ledger and a refresh job that fires at T-7 days from expiry.
Questions an integrator usually opens with
Does the STET PSD2 surface cover the securities portfolio and the Santé/Assurance documents shown in the app, or only payment accounts?
It covers payment accounts and their movements, plus card-based balance checks. The Bourse tile, Assurance contracts, Santé reimbursements and the secure-message channel with the private banker all sit outside the AIS scope. For those we run the authorized interface-integration track against the customer's own session and present both behind one normalized API.
How does Mobile Confirmation interact with periodic AIS reads?
PSD2 SCA renewal for AIS access currently sits at 180 days, subject to ongoing EBA and ACPR guidance. Between renewals the AISP pulls the consented accounts without triggering Mobile Confirmation on the user's phone; sensitive PIS calls still trigger it every time. We bake the renewal countdown into the scheduler and expose a clear consent-expiry timestamp to the integrator.
Banque Transatlantique has Luxembourg, Belgium and UK subsidiaries — does one build cover them all?
No. The Luxembourg entity is supervised by the CSSF, the UK arm by the FCA, with the Belgian activity under the FSMA. Each is reachable through its own AIS regime or local equivalent, and via a separately scoped interface integration. We scope the engagement to the regulator perimeter the customer actually integrates for, and if more than one is in play we deliver one build per perimeter.
Can the integration also fire transfers, or is it read-only?
Both are available, on separate tracks. SCT transfers between own accounts or to a registered beneficiary fall under PSD2 PIS and require a PISP authorization in addition to AIS; we usually run them through a partner PISP unless the customer carries their own. Card opposition and the in-app SCT initiation can also be driven through the authorized interface track when PSD2 is not in scope.
The source-code deliverable — OpenAPI spec, runnable Python and Node modules covering the STET AIS calls and the surfaces we lift from the customer-area protocol, contract and replay tests, the interface documentation — starts at $300 and is paid only once you have taken delivery and signed off on the build. The hosted option is the same surfaces behind our endpoint, billed per call with no upfront fee; the customer keeps the AISP relationship if they prefer to run it under their own ACPR registration. Cycle is 1–2 weeks; access and onboarding are handled with you as part of the engagement. The conversation starts at /contact.html.
Other apps in the same orbit
CIC. The parent bank's own customer app, sharing the Crédit Mutuel Alliance Fédérale STET endpoint; same OAuth pattern, similar consent flow, broader retail product surface.
Crédit Mutuel. The federation's flagship cooperative-bank app, sitting on the same group developer portal; useful when one household has both Banque Transatlantique and a Crédit Mutuel account.
Banque de Luxembourg. Another sister entity under the Crédit Mutuel Alliance Fédérale umbrella; CSSF-supervised, with its own AIS surface for Luxembourg-resident customers.
BNP Paribas Mes Comptes. Major French retail and private-banking app on its own STET endpoint; common alongside Banque Transatlantique in family-office portfolios.
Société Générale. Comparable scope on the cash side; the private-banking branch (SG Private Banking) is often a peer institution on a multi-bank consent.
LCL Mes Comptes. Retail app inside the Crédit Agricole group; appears in cross-bank reconciliation jobs.
Boursorama Banque. Online and brokerage-focused; a common neighbour when an integrator already covers Euronext-side workflow.
La Banque Postale. Universal-bank app with its own STET endpoint; rounds out coverage of French current-account holders inside one consent surface.
How this brief was put together
The in-app feature list was confirmed against the Play Store listing for com.bt_prod.bad (Comptes, Bourse, Assurance, Santé, Mobile Confirmation, RIB/IBAN download, "Je voyage" toggle, Filbanque login). The PSD2 rail was traced through the published CIC STET PSD2 specification and the parallel Crédit Mutuel STET PSD2 specification, both inside Crédit Mutuel Alliance Fédérale. The regulatory framing was checked against the ACPR DSP2 reference page. OpenBanking Studio · integration mapping, 2026-05-29.
Banque Transatlantique mobile — app card
Banque Transatlantique is the private-banking and wealth-management subsidiary of CIC, inside Crédit Mutuel Alliance Fédérale. The mobile customer app offers daily account management, SCT transfers, Euronext securities orders, insurance contracts and claims, Santé reimbursement tracking, document exchange with a private banker, and a travel-notice toggle. Authentication uses the Filbanque credential set plus Mobile Confirmation, with biometrics on supported devices. Listed on Google Play under the package com.bt_prod.bad and on the App Store under id 975158385; subsidiaries in Luxembourg, Belgium, the UK and North America operate under their respective local regulators.