Santander Brasil account data through Open Finance Brasil consent

Banco Santander (Brasil) S.A. is a mandatory participant in Open Finance Brasil, the data-sharing regime the Banco Central do Brasil established under Joint Resolution CMN-BCB No. 1 of May 2020. That single fact decides most of how an integration with the Santander app should be built. The records the app puts in front of a customer — balances, statements, the credit-card bill, Pix and TED history, investment positions — map almost one-to-one onto the consent-based data APIs the bank is obliged to expose. So the cleanest authorized path to Santander data is not scraping a screen; it is a consent the customer grants and can revoke.

This page is for a product or finance team that wants Santander Brasil data flowing into their own system and needs to know the real route and what arrives at the end. Short version: the regulated consent route carries the bulk of it, and we cover the gaps with authorized protocol analysis against a consenting account.

What the app holds, and where it comes from

Each row is a surface the Santander app actually shows a logged-in customer, named the way the app and its Open Finance pages name it.

Authorized ways in

Regulated Open Finance Brasil consent (AIS)

The standardized route. With the customer's consent, the bank's accounts, balances, credit-card, and investment APIs return structured data under the Financial-grade API security profile — mutual-TLS, dynamic client registration against the central directory, and signed requests. Reachable: registration data, account transactions, card invoices and limits, investment lines. Durability is high because the contract is versioned and the Banco Central keeps it stable. Onboarding — directory enrollment, certificates, sandbox access — is work we set up and run with you during the build, not a hurdle you clear first.

Authorized protocol analysis of the app's own traffic

For anything the standard data model does not cover — a specific receipt layout, a Santander Rewards balance, a screen unique to the app — we analyze the app's authenticated traffic against a consenting account and rebuild the request, token, and response chain as code. Effort is moderate; durability depends on the bank's front end, which is why we treat these surfaces with a re-validation step.

User-consented credential access and native export

Where neither of the above fits a niche need, a customer can consent to a credential-based pull, and the app's own receipt-sharing (email, WhatsApp, PDF) gives a low-volume export fallback for proof-of-payment workflows.

For Santander Brasil the regulated consent route is the one we would build the system on: it is the only path that returns balances, card invoices, and investment positions under a permission the customer can withdraw, behind an API the central bank holds steady. The protocol-analysis pass exists to fill the few surfaces the standard scope does not model — we reach for it deliberately, not as the backbone.

The consent handshake, in code

Illustrative shape of a balances pull once consent is granted — field names follow the Open Finance Brasil accounts API and the FAPI flow; the exact directory and token-endpoint values are confirmed during the build against the sandbox.

# 1. Consent already authorized by the customer -> consentId in hand
# 2. mTLS client cert + private_key_jwt assertion authenticate the client
POST /open-banking/accounts/v2/accounts/{accountId}/balances
Host: api.openfinance.santander.com.br        # value confirmed at build time
Authorization: Bearer {access_token}          # scope: accounts, granted via consent
x-fapi-interaction-id: 9f1c-...               # echoed back for traceability

# Expected 200 response (trimmed)
{
  "data": {
    "availableAmount": { "amount": "1543.20", "currency": "BRL" },
    "blockedAmount":   { "amount": "0.00",    "currency": "BRL" },
    "automaticallyInvestedAmount": { "amount": "320.00", "currency": "BRL" }
  },
  "meta": { "requestDateTime": "2026-06-06T12:00:00Z" }
}

# Error handling we wire in:
#   401 -> token expired, refresh via token endpoint
#   403 -> consent revoked or scope missing -> stop, surface to caller
#   429 -> back off per the Retry-After header

What lands in your repo

Every item below is tied to a Santander surface above, not a generic checklist.

• OpenAPI / Swagger spec for the endpoints you need — accounts, balances, transactions, card invoices, investments — as we wire them.
• Protocol and auth-flow report: the consent grant, the FAPI mTLS and private_key_jwt client authentication, token refresh, and the directory registration steps, documented end to end.
• Runnable source in Python or Node.js for the key calls — consent creation, balance and statement retrieval, card-invoice pulls — with the error handling shown above.
• Automated tests against the sandbox and recorded fixtures, including a revoked-consent path.
• Interface documentation a developer can hand to the next person without a walkthrough.
• Compliance and retention guidance: consent scope, expiry windows, and data-minimization notes specific to the permissions you request.

Things we account for on this build

Two details about Santander Brasil shape the work, and we handle both as part of delivery.

• Consent expiry and refresh. Open Finance consents carry a defined lifetime and the customer can revoke at any point. We design the sync around the consent-refresh window so it does not silently lapse, and we treat a 403 on a previously good call as a revocation signal rather than a transient error — the integration surfaces it instead of retrying into a wall.
• The Santander Way migration. Santander states the Way app is being discontinued and its customers moved into the main Santander app for products and services. We build against the surviving app surfaces and avoid binding anything to deprecated Way flows, so a card-data integration does not break when that retirement completes.
• Permission minimization. The regulated scope is granular, so we map your use case to the narrowest permission groups that satisfy it — the consent the customer signs covers only what you actually read.

Access — directory enrollment, certificates, a sandbox or a consenting account — is arranged with you during onboarding. It is our step in the project, run under NDA where needed, with calls logged and data kept to what the consent allows.

Working with us

Source-code delivery starts at $300, and you pay only after the code is in your hands and you have checked it does what this brief describes — runnable source for the Santander endpoints you need, the spec, tests, and the interface docs, on a one-to-two-week cycle. If you would rather not host anything, the second model is a pay-per-call hosted API: you call our endpoints, pay for the calls you make, and there is no upfront fee. Same data either way; the difference is who runs the servers. Tell us the app and what you need from its data and we will scope it — start a conversation here.

Interface evidence

Public Play Store screenshots of the Santander app — the surfaces an integration reads. Tap to enlarge.

How this was checked

Drafted on 6 June 2026 from the app's own Google Play listing and Open Finance pages, cross-checked against the Banco Central do Brasil's Open Finance material and the published Financial-grade API security and dynamic-client-registration specifications. Where a value is bank-specific (token endpoints, directory IDs), the page says it is confirmed at build time rather than stating a number we did not verify.

• Banco Central do Brasil — Open Finance
• Santander Brasil — Open Finance
• OpenID Foundation — Open Banking Brazil FAPI adoption
• Santander Brasil on Google Play

Compiled by the OpenBanking Studio integration desk · 2026-06-06.

Other Brazilian banking apps with the same data shape

Same category, same consent rails — useful when a project needs more than one institution behind one interface. Listed for context, not ranked.

• Nubank — digital account, card, Pix and investments; per-user statements behind a login.
• Itaú Unibanco — full-service retail bank app covering accounts, cards and investments.
• Bradesco — traditional bank app with balances and payments, and a WhatsApp balance link.
• Banco do Brasil — state-owned bank holding accounts, statements and benefit flows.
• Caixa Econômica Federal — accounts plus government-program and benefit data.
• Banco Inter — super-app folding banking, investments and a marketplace together.
• C6 Bank — digital account, cards and investments in one app.
• PicPay — payments wallet with P2P transfers and a transaction ledger.
• BTG Pactual — investment-led app with brokerage positions and balances.

Questions an integrator asks first

Does the Open Finance consent cover card invoices and investment positions, or only balances?

The regulated scope in Brazil runs well past balances. Under the customer's consent it reaches registration data, account transactions, credit-card bills and limits, and the investment and pension lines the app shows under inquiry and redemption. We map exactly which permission groups your use case needs so the consent screen the customer signs is no broader than the data you actually pull.

The app says Santander Way is being discontinued and folded into the Santander app. Does that affect an integration?

It matters for the card-only flows. Santander describes Way customers migrating into the main app for products, information and services, so we build against the surviving Santander app surfaces and avoid wiring anything to the deprecated Way endpoints. If you previously integrated Way, we treat the move as a remap rather than a fresh build.

What keeps the integration working when Santander rotates its mobile front end?

The regulated Open Finance contract is versioned and the Banco Central holds it stable, so a consent-based pull rarely breaks on a UI change. Where we add a protocol-analysis pass for a surface outside the standard scope, we capture the request and token chain as fixtures and re-run them on a schedule, so a changed screen shows up as a failed check rather than silent bad data.

Which regulator and standard governs the Santander Brasil data route?

Open Finance Brasil, established by Joint Resolution CMN-BCB No. 1 of May 2020 and run by the Banco Central do Brasil. The data APIs sit behind the Financial-grade API security profile with mutual-TLS and dynamic client registration against the central directory. Santander Brasil is a mandatory participant, so the consent route is a documented obligation rather than a favour.