Pulling account data out of Nu, country by country

Across Brazil, Mexico and Colombia, Nu carries the balances, Pix history and credit-card limits of more than 105 million people, by its own app-listing count. The data is rich and per-user. What changes from one country to the next is not the data — it is the legal road to it.

In Brazil that road is paved. Nubank is one of the most active members of Open Finance Brasil, so a consent-based read through the regulated APIs is the route we would build a Nu integration on there. Mexico and Colombia each sit at a different point on their own regulatory timeline, and the integration has to respect that. The rest of this brief works through the surfaces, the per-country route, and what we hand over.

Three countries, three regulatory clocks

One target app, three regimes. Treating them as a single integration is the usual mistake; we scope each market on its own terms.

Brazil — regulated consent through Open Finance Brasil

Open Finance Brasil is run by the Banco Central do Brasil and the CMN, and it rolled out in four phases between February and December 2021, covering product data, then customer registration and transactional data, then payment initiation, then investments and insurance. Nubank participates as an S3 institution — not in the mandatory S1/S2 tier, but very much present: reporting on early-2026 call volumes put it as the recipient of roughly 46% of all data shared across the network. For a third party, that means the regulated consent route is real and well-trodden here. Reads go through the Consents API over FAPI-secured OAuth, scoped to what the customer ticks.

Mexico — interface integration while the rules settle

Mexico's Ley Fintech has backed open finance since 2018, and Article 76 names APIs as the sharing mechanism. The catch is that the CNBV and Banco de México have not yet published the secondary rules for transactional data — to date the only secondary regulation issued covers open data for ATMs. So for Cuenta Nu, Cajitas and the Mexican card, we reach the data through authorized, user-consented interface integration rather than a regulated feed that does not exist yet.

Colombia — newly mandatory, mapped to the new decree

Colombia flipped from a voluntary model to a mandatory one. Decree 368, signed in April 2026, stands up the country's mandatory open finance system and obliges credit institutions and other supervised entities to share product, onboarding and account data with authorized recipients. Nu Colombia already holds SFC approval to operate as a financing company. We map a Colombian Nu integration to that framework as it comes into force.

If you only need one market, Brazil's consent route is the cleanest thing to build on: it is regulated, it is the same plumbing Nu itself leans on as the network's biggest data recipient, and it shrugs off app redesigns. Where a country's regulated channel is not yet usable, authorized interface integration of the app's own traffic fills the gap, and native in-app export covers the simple cases.

What sits behind a Nu login

The surfaces below are the ones worth integrating. Each row names where it lives in the app and what an integrator tends to do with it.

What lands at the end of the build

The output is working software plus the paperwork to run and trust it. For a Nu engagement that means:

• An OpenAPI/Swagger spec describing the normalized endpoints we expose for Nu — accounts, balances, Pix transfers, card statements, savings pots.
• A protocol and auth-flow report: for Brazil, the Open Finance Brasil consent lifecycle and FAPI/OAuth token exchange; for the interface route, the login, token-refresh and request-signing chain as we observe it.
• Runnable source for the key reads in Python or Node.js — consent creation, the authorization redirect handler, paged balance and statement fetches, with retry and back-off wired in.
• Automated tests against recorded responses, so a change in a Nu screen or response shape shows up as a red test, not a silent gap.
• Interface documentation and compliance notes: consent scope, retention windows, what is logged, what is minimized.

A consent-and-fetch call, sketched

This is illustrative — resource scopes and endpoint shapes are confirmed against the Open Finance Brasil spec during the build, and tokens are mTLS-bound under FAPI.

# 1) Create a consent (client-credentials token, FAPI headers)
POST /open-banking/consents/v3/consents
  Authorization: Bearer {client_credentials_token}
  x-fapi-interaction-id: {uuid}
  {
    "data": {
      "permissions": [
        "ACCOUNTS_READ",
        "ACCOUNTS_BALANCES_READ",
        "CREDIT_CARDS_ACCOUNTS_READ",
        "CREDIT_CARDS_ACCOUNTS_BILLS_READ",
        "RESOURCES_READ"
      ],
      "expirationDateTime": "2027-06-15T00:00:00Z"   # consent window, up to ~12 months
    }
  }
# -> consentId ; user is redirected to Nu to authorize (OIDC + FAPI)

# 2) After authorization, read with the user-bound token
GET /open-banking/accounts/v2/accounts/{accountId}/balances
  Authorization: Bearer {user_access_token}    # scope tied to consentId
  x-fapi-interaction-id: {uuid}
# 200 -> availableAmount, blockedAmount, automaticallyInvestedAmount
# 429 -> back off; data-recipient call-frequency limits apply
      

The same pattern extends to /credit-cards-accounts for statements and to the Pix transfer resources. For the Mexican and interface-integration paths the call surface differs, but the discipline — explicit consent, scoped token, paged reads, graceful back-off — carries over.

Consent, the regulator, and what's logged

In Brazil the consent is the legal basis. The customer authorizes a specific set of permissions for a fixed period, and that consent can be consulted or revoked through the Consents API at any time; our reads stay inside the granted scope and stop when it lapses or is withdrawn. Across all three countries the posture is the same: access is authorized or user-consented, requests and consent records are logged, only the fields the use case needs are retained, and an NDA covers the work where a client wants one. None of this is a sandbox you have to bring us — onboarding and access are arranged with you as the project starts, against either a consenting account or a sponsor environment.

What we plan around on a Nu build

Two things specific to Nu shape the engineering, and we account for both up front:

• One app, three regulatory states. We pick the route per country rather than assuming Brazil's regulated channel covers Mexico and Colombia. The build is structured so the Brazilian consent path, the Mexican interface path and the Colombian decree-aligned path are separate modules behind one normalized schema.
• Consent expiry and call limits. Open Finance Brasil consents are time-boxed and data recipients face call-frequency limits — Nubank reads at enormous volume precisely because it manages those constraints. We design the sync to renew consent before it expires and to batch reads so the pipeline stays under the rate ceilings rather than tripping 429s.
• A fast-moving front end. Nu ships changes often — Automated Pix, tap-to-pay, the consolidated-limit screen all arrived recently. For any interface-integration path we keep the captured flows under monitoring that flags a shifted screen early, so it is fixed in maintenance instead of surfacing as a dead feed.

How current the data stays

On the regulated route, freshness is a function of two limits: the call-frequency caps the network sets for data recipients, and the consent window itself. Balance aggregation through Open Finance is close to real-time when a read fires; the practical question is how often you are allowed to fire. We tune the polling cadence to the data — balances and Pix more often, statements and investments less — so the feed is current without burning through rate budget. Where a regulated channel is not available, the interface route is scheduled the same way, with a re-auth step when a token ages out.

Screens we mapped against

Public Play Store screenshots of the surfaces referenced above. Select to enlarge.

Where Nu sits among Latin American fintech apps

If your project aggregates more than one account, these are the neighbours a Nu integration usually shares a screen with. Names are listed for context, not ranked.

• Banco Inter — a fully digital bank with checking, investments and a marketplace; broad authenticated-portal data behind one login.
• PagBank — payments and banking from PagSeguro, holding card-acquiring and account balances merchants often need synced.
• Mercado Pago — the wallet inside Mercado Libre, with balances, QR payments and credit lines across the region.
• PicPay — a payments super-app combining wallet, savings and payroll-linked credit.
• Neon — a mobile bank focused on the underbanked, with account and instant-credit data.
• C6 Bank — a digital bank with multi-currency accounts and customizable card programs.
• Will Bank — a mobile-first issuer of credit cards and personal loans.
• Creditas — a secured-lending platform holding loan and collateral data tied to payroll and assets.
• Ualá — a card-led financial app spanning several Latin American markets, with wallet and card-spend records.

What we checked, and when

This mapping draws on the Banco Central do Brasil's Open Finance materials, reporting on Nubank's 2026 share of network data, the OpenID Foundation's account of Brazil's FAPI profile, Nu's own newsroom on in-app balance aggregation, and legal coverage of Colombia's Decree 368. The Mexican picture reflects the still-unpublished CNBV transactional rules. Citations:

• Banco Central do Brasil — Open Finance
• LatamFintech — Nubank's share of Open Finance data exchange
• OpenID Foundation — Open Banking Brazil and FAPI
• Nu International — balance aggregation via Open Finance

OpenBanking Studio · integration desk, reviewed 2026-06-15.

Questions integrators ask about Nu

Does Nu's place in Open Finance Brasil change how its data is reached?

Nubank takes part as an S3 institution and is the network's largest data recipient, per reporting on 2026 call volumes. For Brazil that makes the regulated consent route the natural one: reads run through Open Finance Brasil's Consents API over FAPI-secured OAuth, scoped to exactly what the customer authorizes.

Mexico and Colombia are not on the same regime — how does that shape a Nu build?

They are not. Mexico's Ley Fintech backs open finance, but the CNBV's secondary rules for transactional data are not published yet, so we use authorized interface integration there. Colombia turned mandatory under Decree 368 in April 2026, so we map to its open finance framework. The route is chosen per country.

Which Nu surfaces carry Pix and installment detail?

Pix transfers, including Automated Pix and tap-to-pay, sit in the payments area with timestamps and counterparty keys. Card statements break out purchases and installment plans. Balances and the single-limit screen cover available funds and approved credit. Each maps to a defined resource in the integration.

How current is the data once a feed is running?

Freshness is bounded by the call-frequency limits the network places on data recipients and by the consent window, which runs up to twelve months. We design the sync to refresh on a schedule that stays inside those limits and to renew consent before it lapses.

Source code comes first: you pay after delivery, from $300, once it does what you asked. If you would rather not host anything, call our endpoints and pay per call, with nothing upfront. Either way a Nu build runs in one to two weeks — send us the app name and what you want from its data, and we take it from there. Start at /contact.html.