Pulling account, Pix and investment data from Sicredi X

Sicredi reported reaching ten million members in early 2026, and each one signs into the same cooperative backend that Sicredi X talks to. That backend is regulated. Sicredi is an authorized participant in Open Finance Brasil, the data-sharing regime run by the Banco Central do Brasil, which means a member's account, statement and card data can be reached through a standardized consent flow rather than guesswork. For an integrator, that changes the starting point: the cleanest path into this app is a route the regulator already defines, and most of the engineering is in handling it correctly for a cooperative system rather than inventing access.

This page maps what Sicredi X holds, the authorized ways to reach it, and what we hand over at the end — runnable source for the surfaces you actually need, with the consent and compliance machinery built around it.

Authorized routes into a Sicredi member account

Three routes genuinely apply here. They differ in what they reach, how much they cost to stand up, and how long they keep working without a touch.

1 · Open Finance Brasil consent (regulated AIS)

Sicredi joined the regime voluntarily in its first phase and is a registered participant. Under a member's consent, the standardized APIs carry registration data, checking and savings balances and transactions, credit cards, and credit operations. Reachable surfaces match the regulator's contract, the security model is FAPI over OAuth 2.0 with mutual TLS, and durability is high because the interface is a regulatory obligation, not a private endpoint that shifts with an app release. We register the access and run the consent journey with you as part of the build.

2 · Authorized protocol analysis of the app's traffic

When a surface you want sits outside the regulated contract — a derived view from the financial manager, a screen the standardized APIs do not model — we analyze the authenticated traffic between Sicredi X and its servers under your authorization, document the auth and token chain, and build a client to the relevant endpoints. More effort than the consent route, and it needs a re-check when the app front end changes, but it reaches things the regulated contract does not.

3 · User-consented access with native export as a fallback

For one-off or low-volume needs, a consenting member can authorize access directly, and where the app or web channel offers a statement export, that file becomes a low-cost backfill source. Quick to set up, weaker for anything that has to stay live.

For most projects here, route 1 carries the core read surfaces and is worth standing up first; route 2 fills whatever the regulated contract leaves out. We will tell you which split fits your use case once we see the data you are after.

Data surfaces, and where each one comes from

The financial-manager view and the Theo chat assistant also produce data, but they are derived and conversational respectively — we treat them as optional and only model them when a project asks for them.

A consent handshake, then a balances pull

The shape below is illustrative; exact API versions and scopes get confirmed against the live contract during the build. It follows the Open Finance Brasil pattern: create a consent with the permissions you need, send the member through authorization, then read against the granted scope with a mutual-TLS client.

# 1) Create a consent for the surfaces this project needs
POST /open-banking/consents/v3/consents          # FAPI, mTLS, client_credentials token
{
  "data": {
    "permissions": [
      "ACCOUNTS_READ", "ACCOUNTS_BALANCES_READ",
      "ACCOUNTS_TRANSACTIONS_READ", "CREDIT_CARDS_ACCOUNTS_READ",
      "RESOURCES_READ"
    ],
    "expirationDateTime": "2027-06-11T00:00:00Z"   # <= 12 months, regulator cap
  }
}
# -> 201 { "data": { "consentId": "urn:sicredi:...", "status": "AWAITING_AUTHORISATION" } }

# 2) Member authorizes (redirect / FAPI authorization_code) -> consent status AUTHORISED

# 3) Read against the granted scope
GET /open-banking/accounts/v2/accounts           # authorization_code token bound to consentId
GET /open-banking/accounts/v2/accounts/{accountId}/balances

# response (trimmed)
{ "data": {
    "accountId": "....",
    "availableAmount":   { "amount": "1840.55", "currency": "BRL" },
    "blockedAmount":     { "amount": "0.00",    "currency": "BRL" }
} }

# error handling we wire in:
#   401 invalid_token  -> refresh; if consent revoked, stop and flag re-consent
#   429                -> back off on the participant rate limit
#   consent expiring   -> queue a re-authorization before expirationDateTime
      

How we normalize a Sicredi record

Cooperative addressing does not look like a single account number, so part of delivery is a normalized record your code can rely on regardless of which route filled it. A trimmed example:

{
  "member":     { "cooperative": "0101", "agency": "0710", "document": "***" },
  "account":    { "id": "....", "type": "CACC", "currency": "BRL" },
  "balance":    { "available": 1840.55, "blocked": 0.00, "asOf": "2026-06-11T12:00:00Z" },
  "source":     "open-finance-brasil",      // or "protocol" when the gap route filled it
  "consentId":  "urn:sicredi:..."
}
      

What lands in your repo

Everything is tied to the surfaces above, not a generic kit:

• An OpenAPI/Swagger spec for the endpoints you use — consent creation, accounts, balances, transactions, cards.
• A protocol and auth-flow report: the FAPI/OAuth 2.0 token chain for the consent route, and the documented auth chain for any protocol-analysis gap surface.
• Runnable source for the key calls in Python or Node.js, including the mutual-TLS client, consent lifecycle, and the cooperative-aware account resolver.
• Automated tests against a sandbox or a consenting account, covering token refresh, revoked-consent handling, and rate-limit back-off.
• Interface documentation plus data-retention and consent-logging guidance shaped to LGPD.

Open Finance Brasil, consent, and LGPD

The governing framework here is concrete, not generic. Open Finance Brasil is run by the Banco Central do Brasil under Resolução Conjunta nº 1/2020, and only institutions it authorizes can participate. A member's authorization must be a free, informed, specific act made through a dedicated electronic interface, and consents carry a maximum validity of twelve months before re-consent is required. The technical baseline is the Open Finance Brasil FAPI security profile over OAuth 2.0. The regime keeps moving — Open Finance Brasil published its APIs Manual v7.0 via Instrução Normativa BCB nº 615 in May 2025 and a Customer Experience Manual v8.0 via Instrução Normativa BCB nº 637 in June 2025 — so we pin to the version active at build time and note it in the docs.

Data protection sits under the LGPD, supervised by the ANPD. Our side of that is plain: access is authorized and consent-backed, calls and consent grants are logged, we keep only the fields a project needs, and we work under an NDA where the data warrants it.

Where a Sicredi integration gets fiddly

Two things about this app shape the build, and we handle both rather than hand them to you.

First, the cooperative structure. Sicredi is not one bank but a system of local cooperatives under a shared brand, and a member is tied to a specific cooperative and agency. An account is addressed by cooperative, agency and account number, so we build the resolver to carry that triple end to end and test against more than one cooperative when a use case spans them. A flat single-id assumption breaks quietly here, so we design it out from the start.

Second, the consent clock. Because a grant tops out at twelve months, a sync that is meant to run for years will reach re-consent. We schedule around the refresh window, track each consent's expiry, and raise a re-authorization prompt ahead of the deadline so the feed does not silently go dark. The protocol-analysis surfaces get their own maintenance check, re-run when the app front end shifts — the recent move from the older Sicredi app to Sicredi X, with its card-password-plus-email login, is exactly the kind of change we watch for.

Pricing and how a build runs

Source for the Sicredi endpoints you need lands in your repository from $300, billed only after you have run it and signed off — nothing upfront, and you pay once it does what you asked. If you would rather not host anything, the same surfaces are available as a pay-per-call hosted API: you call our endpoints and pay only for the calls, with no setup fee. Either way the cycle is one to two weeks, and access and compliance steps are arranged with you as part of the work. Tell us the app and what you want out of it, and we will scope it — start at /contact.html.

Screens we worked from

Store screenshots used while mapping the surfaces above. Select one to enlarge.

Sources and review

Surfaces were checked against the Play Store listing and the app description; the regulated route was checked against the Banco Central Open Finance page, Sicredi's developer portal for Open Finance, and the Open Finance Brasil normative acts, on 11 June 2026. Citations:

• Banco Central do Brasil — Open Finance
• Sicredi Desenvolvedores — APIs Open Finance
• Open Finance Brasil — atos normativos
• Sicredi X — Google Play listing

Mapped by the OpenBanking Studio integration desk, June 2026.

Nearby Brazilian finance apps

Same-category apps an aggregation or reconciliation project often touches alongside Sicredi X. Listed for ecosystem context, not ranking.

• Sicoob — the other large Brazilian credit-cooperative system, with the same cooperative-and-agency account model.
• Nubank — digital bank holding accounts, cards and Pix, and an Open Finance participant.
• Neon — digital-account fintech centered on Pix, cards and everyday banking.
• Iti — Itaú's digital wallet and account, folded into the Itaú super app.
• C6 Bank — full-service mobile bank with accounts, cards, investments and global accounts.
• Banco Original — digital banking for individuals and businesses.
• Banco Safra — banking and investment products across personal and corporate lines.
• Genial Investimentos — an investment platform holding brokerage positions and balances.
• Woop Sicredi — Sicredi's own digital-account app, a sibling product holding overlapping account data.

Questions integrators ask us about Sicredi

Sicredi runs as a network of local cooperatives — does that complicate an account integration?

It shapes the work. A member belongs to a specific cooperative and agency, and an account is addressed by cooperative, agency and account number rather than one flat id. We map that routing so a member at one cooperative resolves to the right backend, and we test against more than one cooperative when a use case spans them.

Would you reach the data through Open Finance Brasil or through the app's own traffic?

Where regulated read access covers what you need — registration data, balances, transactions, cards, credit operations — Open Finance Brasil consent is the cleaner path, because Sicredi is an authorized participant and the data contract is standardized. When a surface sits outside that contract, we analyze the app's authenticated traffic under your authorization and build to it. Most projects use consent for the core and protocol work only for the gaps.

Can a Pix be initiated through Sicredi, or is this read-only?

Both exist. Open Finance Brasil separates data sharing from payment initiation, and Sicredi supports Pix initiation through authorized initiators as well as read access to accounts. We scope payment initiation separately because it carries its own consent type and liability model, and we tell you up front which one a project needs.

What happens when a member's consent reaches its limit?

Open Finance consents carry a maximum validity of twelve months, so a long-running sync eventually hits re-consent. We build the refresh window into the schedule, track each consent's expiry, and surface a re-authorization prompt before it lapses rather than letting the feed go quiet.