Reaching Caixadirecta's multi-bank account data through Portugal's AIS rails

Caixa Geral de Depósitos sits at register number 35 on the Bank of Portugal's books, as the app's Play Store description states, and its retail app already does something most bank apps don't: it pulls balances from accounts the customer holds at other banks and shows them next to the CGD ones. That detail shapes every integration decision here. The account ledger a buyer usually wants — balances and dated transactions for a CGD account — rides Portugal's PSD2 account-information rails. The cross-bank tiles, MB WAY, and product subscription sit on surfaces that those rails don't standardize, and they need separate handling. This page maps both halves and the authorized way into each.

What sits behind a Caixadirecta login

The app names its own surfaces; the table keeps that vocabulary rather than a generic export list. Granularity below reflects what a PSD2 account read returns plus what the app exposes on screens we examined.

Authorized ways into the account feed

Three routes apply to this app. Each is described by what it reaches, how durable it is, and what we set up to run it — onboarding and access are arranged with you during the project, not asked of you up front.

1 · Regulated PSD2 AIS via SIBS API Market

SIBS runs Portugal's shared open-banking hub on the Berlin Group NextGenPSD2 standard, and CGD is one of the participating banks. A consent gives a registered account-information provider the customer's CGD account list, balances, and booked transactions. Strong customer authentication happens inside the Caixadirecta app itself — biometrics or PIN — which is convenient, because that is the exact app you are integrating against. It is the most durable channel: documented fields, versioned, and unaffected when CGD restyles its front end. We handle the TPP onboarding and sandbox access with SIBS as part of the build.

2 · Authorized protocol analysis of the app's own traffic

Some surfaces never appear in the PSD2 spec: the aggregated other-bank tiles, MB WAY events, product subscription. For those we work from the app's own client-server traffic, under your authorization and against a consenting account, treating it as reverse engineering for interoperability — mapping request shapes, the token and session chain, and response schemas. More maintenance than route 1, but it reaches what the regulated channel leaves out.

3 · User-consented session access

Where a single account holder authorizes a direct pull, a consented session can stand in for a full TPP setup during a pilot. Narrower and shorter-lived, useful to prove a flow before the AIS onboarding completes.

For the account ledger itself the SIBS AIS channel is the one we'd build on — it is documented, it survives app redesigns, and CGD already runs its strong-authentication step through the Caixadirecta app you are targeting. Protocol analysis earns its place for the things AIS does not standardize: the cross-bank tiles, MB WAY, product subscription. Most projects here use both, each for the part it fits.

A consent-and-fetch sketch

This is the shape of an AIS read against the SIBS hub, not copy-paste code. Field names get confirmed against the SIBS sandbox during the build, never asserted from this page.

# Illustrative - Berlin Group NextGenPSD2 consent + account read via SIBS API Market.

POST /v1/consents  HTTP/1.1
Host: <participant>.sibsapimarket.com
TPP-Redirect-Preferred: true
PSU-IP-Address: 198.51.100.7
Content-Type: application/json

{
  "access": { "balances":    [{ "iban": "PT50 0035 ..." }],
              "transactions": [{ "iban": "PT50 0035 ..." }] },
  "recurringIndicator": true,
  "validUntil": "2026-09-13",     # ~90-day AIS consent ceiling
  "frequencyPerDay": 4            # PSD2 unattended-access cap
}

# 201 -> { "consentStatus": "received",
#          "_links": { "scaRedirect": { "href": "https://.../sca" } } }
# PSU approves in the Caixadirecta app (biometric / PIN), consent goes "valid", then:

GET /v1/accounts/{resourceId}/transactions?bookingStatus=booked
Consent-ID: 3f9c-...
# 200 -> { "transactions": { "booked": [
#   { "bookingDate": "2026-06-11",
#     "transactionAmount": { "amount": "-42.30", "currency": "EUR" },
#     "creditorName": "...",
#     "remittanceInformationUnstructured": "..." } ] } }

# Handle 401 expired-consent by triggering re-auth before the 90-day window closes,
# not after a read has already failed.
      

What lands at the end

Everything below is tied to the surfaces above, not a stock deliverables list:

• An OpenAPI/Swagger spec for the CGD AIS endpoints you consume — accounts, balances, transactions — plus any app-specific surface in scope.
• A protocol and auth-flow report: the Berlin Group consent lifecycle, the app-based SCA redirect, Consent-ID and token handling, and the 90-day renewal path written out.
• Runnable source in Python or Node for consent creation, SCA-redirect handling, account and transaction paging, and the MB WAY surface where you need it.
• Automated tests against the SIBS sandbox or a consenting account, so the renewal and paging logic is exercised, not assumed.
• Interface documentation plus consent-record and data-retention guidance fit for a Banco de Portugal-supervised flow.

Consent and the Portuguese rulebook

This is an EU PSD2 setting. Portugal transposed the directive through Decreto-Lei n.º 91/2018 of 12 November, and Banco de Portugal supervises it and registers the account-information providers that operate under it. Access is consent-first: the account holder authorizes a named provider, strong customer authentication runs through the Caixadirecta app, and the consent carries a scope and an expiry that renews at roughly 90 days. Unattended reads are capped under the standard, which is why the polling cadence is a design choice rather than an afterthought. On our side the work stays authorized, logged, and data-minimized to the fields you actually use, with consent records kept and an NDA where the engagement calls for one. The cross-bank and MB WAY surfaces reached by protocol analysis run under your written authorization against a consenting account, and the same data-minimization applies.

Things we account for in the build

Two specifics about this app drive most of the engineering decisions, and we handle them as part of the work:

• Native versus aggregated balances. The accounts list mixes CGD accounts with tiles aggregated from other banks. We mark each balance by origin so the integration never treats a second-hand aggregated figure as a directly-sourced CGD AIS value — they have different freshness and different authorization basis.
• SCA tied to the app, on a clock. Because strong authentication and the 90-day consent both run through the Caixadirecta app, we build the refresh to re-prompt the account holder ahead of expiry, so a long-running sync re-validates on schedule instead of going dark on a 401.
• MB WAY scoped on its own. MB WAY is a SIBS rail, not the account ledger, so we map its events as a separate feed and reconcile against the statement rather than assuming overlap.
• Front-end drift. For the protocol-analysis surfaces we keep a re-check in maintenance so a CGD app redesign is caught and the mappers updated before they silently return stale shapes.

Where teams point this

• A Portuguese accounting SaaS reconciling client CGD statements every night against issued invoices.
• A lender reading roughly 90 days of booked transactions for an affordability check under a one-off AIS consent.
• A budgeting or PFM app merging CGD balances with the user's other-bank tiles into one view.
• A treasury tool watching scheduled-transfer status and payout execution across a company's CGD accounts.

Screens we worked from

Public store screenshots used while mapping the surfaces above. Tap to enlarge.

How this mapping was put together

The app's described surfaces were read against the store listing, and the route was checked against Banco de Portugal's PSD2 pages, the SIBS API Market developer material, and the Decreto-Lei 91/2018 summary — all in June 2026. Sources we opened:

• Banco de Portugal — Payment services under PSD2
• SIBS API Market developer portal
• CGD — SIBS API Market notice
• Decree-Law no. 91/2018 summary

OpenBanking Studio · integration desk mapping, June 2026

Other Portuguese money apps in the same picture

An aggregation or accounting product rarely stops at one bank. These sit in the same Portuguese open-banking landscape; named here only to widen the picture, not to rank them.

• Millennium BCP — the largest private bank's app; current accounts, cards and transfers behind a login, reachable on the same SIBS rails.
• Santander Portugal — retail accounts, cards and mortgage data in its app.
• novobanco — accounts, transfers and card controls for its retail base.
• ActivoBank — Millennium BCP's digital bank; day-to-day accounts and payments.
• Banco Montepio — accounts, savings and payment operations.
• EuroBic — current accounts and domestic transfers.
• MB WAY — SIBS' phone-number payment app, peer transfers and ATM cash-out across Portuguese banks.
• Revolut — multi-currency balances, cards and transaction history widely used by Portuguese residents.
• N26 — a German-licensed account popular in Portugal, with its own statement feed.
• Wise — multi-currency balances and cross-border transfers held server-side.

Questions integrators ask about Caixadirecta

Does this reach only CGD accounts, or also the other-bank balances Caixadirecta shows?

A PSD2 AIS consent at Caixa Geral de Depósitos exposes the customer's own CGD accounts — balances and booked transactions. The other-bank tiles inside the app are aggregated by CGD itself, so reaching those cleanly means a separate AIS consent at each of those banks, or working with the app's aggregated view directly. We scope which of the two you need before building.

What consent window does a Portuguese AIS feed run on?

AIS consent under the Portuguese transposition of PSD2 caps unattended access and renews at roughly 90 days, with strong customer authentication done through the Caixadirecta app by biometrics or PIN. We design the refresh to re-prompt the account holder before the consent lapses, so the sync does not quietly stop returning data.

How is MB WAY data different from the account statement feed?

MB WAY is a SIBS phone-number rail layered on top of the bank, not part of the standardized PSD2 account ledger. Its sends, requests and ATM withdrawals are a distinct surface; we map them apart from the balances-and-transactions feed rather than assuming one covers the other.

Does someone have to approve every pull, or only the first one?

Strong customer authentication approves the consent, not each read. Under PSD2 an account information service may then access the account unattended up to four times a day, with anything beyond that requiring the account holder again. We tune the polling cadence to live inside that limit.

Working with us

Source code lands first: you see the working integration before any invoice, from $300, paid once it does what you asked. The other model is pay-per-call — you hit our hosted endpoints and pay only for the calls you make, with nothing up front. Either way the build runs on a one-to-two-week cycle. Tell us the app name and what you need from its data, and the access and compliance steps get arranged with you from there — start at /contact.html.