Bringing DaviPlata's wallet ledger into your own systems

Behind a DaviPlata login sits a Davivienda-operated wallet ledger: a balance, the Bre-B key directory, PSE top-ups, national and international transfers, and the movements of a 100% digital Mastercard debit card. None of that is a file on the phone. It is server state held by a regulated bank, which is exactly the kind of data a payroll platform, a lender doing affordability checks, a remittance company, or a marketplace settling with sellers wants to read in a structured form. This brief sets out what that data is, the authorized way we reach it for you, and what we hand back.

The honest summary first. Colombia has a real open-finance regime, but its transactional phase is mid-rollout and its deadlines keep moving. So the route we actually recommend for DaviPlata is a hybrid: use the Sistema de Finanzas Abiertas consented contract where Davivienda exposes it, and run an authorized protocol-analysis integration against a consenting account for everything not yet served that way, with statement-file parsing closing the gap on older history.

What sits behind a DaviPlata login

These are the surfaces a real DaviPlata account holds, named the way the app presents them in Spanish where that matters for mapping.

Routes that apply here

Sistema de Finanzas Abiertas consent

Davivienda is an SFC-supervised bank and a participant in Colombia's open-finance system. Where it has the consented contract live, this is the cleanest path: standardized REST, OpenAPI description, OAuth 2.0, JSON payloads, with the consumer authorizing the data share. Reach is good for products, balance and movements as the transactional phase comes online. Durability is high because it is regulated and versioned. We handle the participant onboarding and consent registration with you as part of the build.

Authorized protocol analysis of the app's traffic

For surfaces the open-finance contract does not yet expose for this institution, we map the app's own client-to-server protocol against an account the customer controls and consents to. Reach is broad — effectively whatever the app itself can show. Effort is higher and durability is medium: the front end changes, so we wire a maintenance check for that. This is the workhorse route for DaviPlata today.

Statement-file parsing

Older periods leave the live view and live only in downloadable statements. We parse those documents into the same normalized schema as the live feed. It is the dependable fallback for history depth, not a primary real-time route.

Recommendation in plain terms: build the protocol-analysis integration as the backbone now, fold in the open-finance contract for the fields Davivienda already serves under it, and use statement parsing to backfill history. As the SFC transactional phase lands for the participant, more of the backbone shifts onto the regulated contract without the consumer-facing behaviour changing.

A worked example: reading the movement ledger

Illustrative shapes, confirmed and pinned during the build against a consenting account — field names follow what the app uses.

# 1. Establish an authorized session (open-finance OAuth where live,
#    otherwise the app's own consented auth chain, abstracted behind one client)
POST /auth/token
  grant_type=authorization_code  scope="cuentas movimientos llaves"
  -> { "access_token": "...", "refresh_token": "...", "expires_in": 1800 }

# 2. Resolve the wallet and read balance
GET /v1/cuentas
  Authorization: Bearer 
  -> { "cuentaId": "wlt_*", "saldo": 184350.00, "moneda": "COP",
       "bolsillos": [ { "nombre": "Mi bolsillo", "saldo": 50000.00 } ] }

# 3. Page the movement ledger (live window)
GET /v1/cuentas/{cuentaId}/movimientos?desde=2026-04-01&hasta=2026-05-16&cursor=
  -> { "items": [
        { "fecha": "2026-05-14T09:21:00-05:00", "tipo": "TRANSFERENCIA_BRE_B",
          "valor": -75000.00, "contraparte": { "llave": "3xx-xxx", "entidad": "—" } },
        { "fecha": "2026-05-12", "tipo": "DEPOSITO_PSE", "valor": 300000.00 } ],
       "next_cursor": "eyJwIjoy..." }

# 4. Backfill closed periods from statement files, normalized to the same record
GET /v1/cuentas/{cuentaId}/extractos?periodo=2026-03  -> application/pdf
  parsed -> movimientos[]  (same schema as step 3)

# Errors are normalized: 401 -> refresh via refresh_token; 409 -> consent
# expired/revoked, surface for re-consent; 429 -> backoff with jitter.
      

What lands in your repo

Deliverables are tied to the surfaces above, not a generic checklist.

• An OpenAPI 3 specification covering balance, the movement ledger, Bre-B key resolution, PSE deposit records, digital-card movements and statement backfill.
• A protocol and auth-flow report: the token/refresh chain, consent and revocation handling, pagination cursors, and the statement-file format with its parsing rules.
• Runnable source for the key endpoints in Python and Node.js, with the normalization layer that makes statement lines and live movements one schema.
• Automated tests against recorded fixtures, including consent-expiry and rate-limit paths.
• Interface documentation plus data-retention and consent-logging guidance scoped to Colombian rules.

Where this sits under Colombia's open-finance rules

The regime is Colombia's Sistema de Finanzas Abiertas. Decreto 1297 de 2022 modified Decreto 2555 de 2010 to allow financial-consumer data exchange; the Superintendencia Financiera then set the technical and security standards in Circular Externa 004 de 2024 — REST APIs with OpenAPI, OAuth 2.0, JSON. Transactional movements and payment initiation belong to the model's second phase. The point to be honest about: this is not a settled steady state. The transition window in CE 004 was extended by Circular Externa 009 de 2025 and again by Circular Externa 001 de 2026, so we do not quote a fixed live-by date as fact — we design for both the consented contract and the protocol-analysis path so the integration works whatever Davivienda has switched on at the time. Consent is explicit, scoped, time-bound and revocable; we keep consent records and access logs, minimize stored fields to what the use case needs, and work under an NDA where the engagement calls for one.

What we plan for on a DaviPlata build

Concrete things this app forces, all handled on our side:

• The July 2025 Bre-B key change. The old "Zona Llaves" model was replaced by "Mis llaves Bre-B," with multiple key types per wallet and a revised key protocol. We map key resolution against the current scheme so payee lookups stay correct rather than coded to the retired flow.
• The statement boundary. Live movements and downloadable extractos are two different sources with different fidelity. We design the sync to stitch them into one continuous, de-duplicated series so history does not break at the on-screen window edge.
• Mixed identity documents. Registration spans a Colombian ID, a foreign resident ID, and the PPT. We carry a document-type discriminator through identity and account resolution so non-citizen accounts are not silently dropped.
• Consent lifecycle. We build the sync around the consent-refresh and revocation window so it surfaces a re-consent prompt instead of failing quietly when authorization lapses.

Scenarios this gets used for

• A lender reads balance and the movement ledger for a consenting applicant to score cash flow, then revokes access after the decision.
• A payroll or G2P disburser resolves a recipient by Bre-B key and confirms the credit landed via the movement feed.
• A remittance firm reconciles inbound international transfers against the wallet ledger for its compliance file.
• An accounting platform pulls digital-card movements and statement backfill to categorize a microbusiness's spend.
• A marketplace settles with QR-collecting sellers by matching merchant-collection receipts to payouts.

Interface evidence

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

The wallet field around DaviPlata

Same-category Colombian apps an integrator often has to cover alongside DaviPlata. Names are listed for context; one unified integration usually spans several.

• Nequi — Bancolombia's digital wallet, with balance, transfers and goal pockets behind an authenticated account.
• MOVii — a fully digital financial platform aimed at unbanked users, holding wallet balance and transaction history.
• Dale! — Grupo Aval's wallet for digital payments and purchases without a group-bank account.
• RappiPay — a Rappi–Davivienda venture, now a digital bank, with wallet and card data behind login.
• Lulo Bank — a branchless neobank backed by Grupo Gilinski, holding accounts, cards and movements.
• Mercado Pago — Mercado Libre's wallet in Colombia, with balance, PSE top-ups and card-linked spend.
• Walo — a newer Colombian fintech offering transfer, payment and withdrawal records.

Questions integrators ask about DaviPlata

Can you separate the Bre-B key directory from the underlying wallet movements?

Yes. A Bre-B key (phone, ID document, email, or alphanumeric code) is a resolution layer that points at an account; the movement ledger and balance are a different surface. We model them as separate objects so a key lookup, a balance read, and a transaction pull each have their own contract and can be consented to independently.

How do you get statement history older than what the app shows on screen?

DaviPlata shows recent movements live but routes older periods through downloadable statement files. We build the ledger sync to stitch the live feed together with parsed statement documents, so history beyond the in-app window is normalized into one continuous series rather than lost at the screen boundary.

Does Colombia's Sistema de Finanzas Abiertas cover the transactional data we want from DaviPlata?

Transactional movements and payment initiation fall under the second phase defined by Circular Externa 004 de 2024 from the Superintendencia Financiera. The transition timeline has been extended more than once, so we design the integration to use the consented open-finance contract where the participant has it live and a protocol-analysis path against a consenting account where it is not yet exposed.

We onboard users with a PPT instead of a Colombian cedula — does that change the identity mapping?

It does, and we account for it. DaviPlata registers people on a foreign resident ID or a Temporary Protection Permit as well as a national ID, so the profile and account-resolution layer has to carry a document-type discriminator rather than assume one ID format. We map every supported document type so non-citizen accounts resolve correctly.

Sources checked for this brief

Surfaces and the regime were checked in May 2026 against the app's own pages and Colombian regulator material: DaviPlata's Bre-B keys guide and its digital debit card page for the data surfaces; the Superintendencia Financiera's open-finance announcement and the text of Decreto 1297 de 2022 for the regime. User figures are as Davivienda reported them for 2024 and are quoted as such, not asserted independently. Compiled by the OpenBanking Studio integration desk; sources rechecked 16 May 2026.

Source for the endpoints you need lands in your repository inside one to two weeks, billed from $300 and only once you have checked it works against your own DaviPlata account; if you would rather not host anything, the same surfaces are available as our pay-per-call API with nothing paid upfront. Send the app name and what you need from its data through our contact page and we scope it back to you.