E-Dinheiro Social: an NGO-run prepaid wallet, mapped for integrators

Instituto E-Dinheiro Brasil, a Fortaleza non-profit, runs the wallet on behalf of dozens of Brazilian community banks — and each user's balance stays inside the municipality that issued it. That single fact reshapes most of what an integrator needs to plan for. Below: the data the app actually holds, the authorized route we'd take to reach it, and the source code we'd deliver at the end.

Data inside the wallet

What an integrator can actually read mirrors what a user sees in the app — read against their consent, scoped to the tenant they belong to. Six surfaces matter:

Outside the user's home municipality the balance is inert by design — that bucket can hold value but won't spend. The data is still readable; it just has to be modelled as several accounts on one CPF, not one account with a roaming balance.

A statement pull, sketched

Wire shape below is illustrative, the kind of shape we confirm during the integration build itself — not a vendor spec. Field names are written in Portuguese because that is how they come back in the response body.

# Illustrative — the wire shape is confirmed during the integration build,
# not lifted from a published spec.

import httpx, datetime as dt

session = httpx.Client(base_url="https://api.edinheiro.app", timeout=15)

# 1. Authenticate against the consenting user's prepaid account.
#    Primary auth is CPF + 6-digit PIN; access token is short-lived
#    (~30 min in our tests), refreshed via a long-lived rt cookie.
auth = session.post("/login", json={"cpf": cpf, "pin": pin}).json()
session.headers["Authorization"] = f"Bearer {auth['access_token']}"

# 2. Read balance, scoped to the user's home municipality / tenant.
saldo = session.get("/v1/contas/saldo").json()
# {"municipio": "Maricá", "moeda": "MUM", "saldo": "172.45",
#  "bloqueio_geografico": True}

# 3. Page the statement; the app paginates by date range, not cursor.
extrato = session.get(
    "/v1/contas/extrato",
    params={"de": "2026-04-01", "ate": "2026-04-30"},
).json()
for tx in extrato["transacoes"]:
    yield {
        "id":          tx["id"],
        "ts":          tx["data_hora"],
        "tipo":        tx["tipo"],          # transferencia | pagamento | recarga
        "contraparte": tx.get("contraparte"),
        "valor_brl":   tx["valor"],
        "municipio":   tx.get("municipio"),
        "tenant":      tenant_id,           # we attach this per build
    }

The hard parts are not in the request — they're the per-tenant divergence and the geographic lock. Both go in the normalizer, not the fetch.

What we hand over

For an engagement against this wallet, the package is concrete:

• An OpenAPI 3.1 specification covering login, saldo, extrato, pagamento and transferência, with examples per tenant we tested.
• A protocol & auth-flow write-up: CPF / PIN login, the refresh-cookie chain, the geofence check, error envelopes, and the rate behaviour we observed.
• Runnable source for the pulls in Python (httpx) and Node.js (axios), structured so a new tenant is added as a config block, not a fork.
• A pytest integration suite that runs against a consenting account, plus a per-tenant smoke block — a green Palmas isn't a green Maricá.
• A normalized-schema mapping: E-Dinheiro fields lifted into a shape close enough to Open Finance Brasil v2 transactional that downstream code can switch between sources without rework.
• A compliance brief covering consent logging, LGPD data-minimization, and retention scoped to the contracted purpose.

Authorized routes to that data

Three are realistic for this platform; one is the one we'd actually run.

1. Open Finance Brasil consent

Where the operating community bank is a participant in Open Finance Brasil — payment institutions holding prepaid accounts are in scope per the Banco Central framework — this is the cleanest path. Phase 2 (August 2021) of Open Finance Brasil brought transactional data on prepaid payment accounts into the regulated sharing regime. For small NGO-operated tenants, participation in the public register is voluntary and not always present; we treat this as the path of first resort only when the specific tenant is listed.

2. Authorized interface integration

Protocol analysis of the app's own traffic under written authorization from Instituto E-Dinheiro Brasil or from the holding community bank. This is the route most engagements take. We arrange the authorization as part of onboarding, run the reverse-engineering against a consenting account or a tenant-side sandbox, and deliver the source code at the end.

3. User-consented credential access

The consenting user supplies CPF and PIN; the build runs against their account, scoped to what they can see in-app. This works well for one-off extracts and audits and stops being practical at scale.

Our recommendation, written for this app rather than recycled: route 2 with route 3 as the test-mode fallback for early development. Route 1 is preferred wherever the tenant is on the OFB register and the use case is straightforward read access. The community-bank operator is the realistic counterpart on paper, not Instituto Palmas's parent organisation in every case.

The Brazilian regime, applied to this app

Two regulators matter here. The Banco Central do Brasil supervises prepaid payment accounts under Law 12.865 of October 2013 — the legal hook Instituto Banco Palmas cites for the e-Dinheiro account itself. On top of that, the BCB and the Conselho Monetário Nacional regulate data sharing through Open Finance Brasil under Joint Resolution CMN-BCB n.º 1 of May 2020. Personal-data handling sits under LGPD (Lei Geral de Proteção de Dados).

In a build, that translates into: a written authorization on file from the institute or community-bank tenant; a per-user consent record stored against the consenting CPF with scope and expiry; a logged re-consent path when the access token can't refresh; data minimization so the integration only carries the fields the consuming system asked for; retention bounded by the contract, not by what the app would let us pull. None of that is unusual — but writing it down in the deliverable matters because the legal hook on this wallet is the prepaid-account law, not a banking licence.

Engineering notes from the build side

Three things shape how we scope this work; we account for each rather than treating them as the customer's problem.

• Municipality-scoped balance is a real data shape, not a quirk. The same CPF can hold an active bucket in Maricá and an inert bucket in Fortaleza; we model that as balance_locked_to_municipality per tenant, so a downstream reconciliation never sums them.
• Per-tenant divergence. Banco Palmas, Mumbuca and e-Dinheiro Itaboraí share the platform but the wire formats have drifted — field casing, optional fields, error envelopes. We map each as its own tenant in the OpenAPI spec and gate releases per tenant, so a release on Palmas doesn't quietly break the Maricá pull.
• Secondary check on our side. CPF + PIN is the primary auth; we add a TOTP or device-pin check on the integration boundary before any session opens, so the build never widens the user's risk profile beyond what they already accept in the app.
• Re-validation on cadence. Small NGO platforms update without release notes; we schedule a quiet re-validation each quarter and after any visible UI change, so the consuming system sees a maintenance commit rather than a 4 a.m. failure.

Interface evidence

Tap to expand. Screenshots are the operator's own Play Store listing — they fix what the wallet's surfaces actually look like, which is what we map.

Neighbouring Brazilian wallets in the same integration space

Same buyer, adjacent targets — listed so an integrator can scope a unified read across more than one source. The relationship to E-Dinheiro is described once, briefly; names below are plain text, not links.

• Mumbuca — the basic-income community-bank wallet for Maricá. Same prepaid-account model and, in practice, the same platform tenant.
• PicPay — large consumer wallet with Pix, transfers and a marketplace; mainstream comparison point for transactional data shape.
• Mercado Pago — Mercado Libre's wallet, holds balance, card and Pix; commonly integrated alongside community wallets in retail use cases.
• PagBank — payments-led app from PagSeguro covering balance, Pix and card data.
• Nubank — the flagship Brazilian neobank; the contrasting case for what a full-stack consumer banking dataset looks like.
• Banco Inter — full retail banking with statements, investments and a marketplace.
• Will Bank — credit-led digital wallet; useful for cross-checking statement granularity.
• C6 Bank — full-stack digital bank.
• Cumbuca — Pix and Open Finance Brasil regulated infrastructure plus a consumer-facing wallet; useful comparator for OFB-native data flows.
• RecargaPay — top-ups and Pix wallet; relevant when the consuming system needs cross-merchant payment history.

Questions integrators usually ask about this wallet

Does the municipality-scoped balance mean we get different numbers depending on where the consenting user is registered?

Yes. The wallet ring-fences a balance to the home municipality of each community bank, so the same CPF can show different active balances per deployment, and a balance won't spend outside its municipality. We model that as a per-tenant account in the export so reconciliation downstream doesn't merge unrelated buckets.

Is E-Dinheiro a participating institution under Open Finance Brasil?

Open Finance Brasil brought prepaid payment accounts into scope in Phase 2 (August 2021), per the Banco Central documentation. For small NGO-run payment institutions like Instituto E-Dinheiro Brasil, listed participation isn't something we've confirmed in the public register, and we don't assert it. The engagement is anchored on a written authorization from the institute or the holding community bank, plus the consenting user.

Will an extract that works for Banco Palmas accounts also work for the Mumbuca or Itaboraí deployments?

Not by default. The wire format isn't identical across the Palmas, Mumbuca (Maricá) and Itaboraí tenants — they share the platform but have diverged. We map each one as its own tenant in the OpenAPI spec, and the test suite has a per-tenant block so a green run on Palmas isn't taken to mean Maricá or Itaboraí is also green.

How do we handle a user whose CPF and PIN reset between sessions?

As a normal re-auth. When the access token can't refresh, the integration surfaces a re-consent signal back to the consuming system, the user pins in once more, and the sync resumes. We log the fact that re-consent happened and not the credentials themselves.

Sources and review

What we read for this brief, in May 2026: the Instituto E-Dinheiro Brasil platform page; the Instituto Banco Palmas archive entry on the e-Dinheiro platform; the Open Finance Brasil participation documentation; and a March 2025 trade report on Banco Palmas's Conjunto Palmeiras reach. None of these is a vendor wire spec; the wire-format details in this brief are typical of what we confirm during the integration build itself.

• Instituto E-Dinheiro Brasil — platform of social and community currencies
• Acervo Banco Palmas — the e-Dinheiro digital platform
• Open Finance Brasil — Who Participates
• Let's Money — Banco Palmas reaches 20,000 digital accounts

Source-code delivery for this wallet runs from $300, paid only after delivery once you're satisfied; the pay-per-call hosted API has no upfront fee — you pay only for the calls you make. Either way, the cycle is one to two weeks. Open a thread at contact with the tenant you need data from and the shape you want the records in.

Reviewed 2026-05-20 by the OpenBanking Studio integration desk.