How a third-party system reaches account data inside Banco Popular Dominicano

More than 45 million transactions a year flow through the Popular App, according to figures the bank shared on its 60th anniversary, and the data behind those flows is what a third-party system actually wants to reach — balances and movements across peso, dollar and euro cuentas, credit-card and loan ledgers, transfers between own accounts and to third parties, and the Popular Token authentication that gates the lot. This brief sets out what is reachable inside Banco Popular Dominicano, the authorized route we run today while the Dominican open finance framework is still being drafted, and the runnable source we hand over at the end of the build.

What lives behind the login

The Popular App is one of the more feature-dense Dominican banking apps — the bank itself describes more than fifty self-service features in the channel. The surfaces worth integrating, named the way the app names them, are these.

How we get there

There are three working routes for Banco Popular Dominicano today, plus a fourth that the Superintendencia de Bancos is openly preparing for the medium term.

Account-holder-consented interface integration

The build runs through the same surfaces the user already sees in the Popular App, against the same login and Popular Token they already use. This is the route that actually delivers in the current Dominican landscape, because it does not depend on a regulatory standard that has not landed yet. Effort sits in mapping the Spanish field names cleanly into your schema and in keeping the OTP refresh aligned with long reads.

Native export as a low-fidelity fallback

Popular's Internet Banking surface produces account statements as PDF and CSV. Where a client only needs end-of-month reconciliation, we wire that as a secondary path — cheaper, less granular than the live read, and useful as a check against the primary feed. It does not replace the interface integration; it complements it.

tPago and sister-app channels

tPago is the Popular-operated mobile-payments rail and shares some of the same back-end. Where a client needs both retail and tPago activity, we treat them as related but distinct collections, because the transaction model and the auth chain are not identical. Sister apps Comerza, Yava and Gnial run on the same infrastructure for different segments; if the integration target is one of those, the route is the same shape but the surface map is different.

The forthcoming open finance route

The Superintendencia de Bancos, Adofintech and the Hub de Innovacion Financiera have been hosting the Open Banking Forum series and signed a letter of commitment with the IFC for the design of an open banking framework. Once that lands as a regulated AIS regime, we expect Banco Popular Dominicano to expose a consent-based read endpoint and the integration will migrate onto it. Until then the framework is in development, not in force, and we say so on the page rather than pretending otherwise.

The route we recommend for any current build is the account-holder-consented one, with native export wired as a secondary check, and a stub left in the codebase for the eventual SB framework so migrating later is a switch rather than a rewrite.

What lands in your repo at handover

The deliverable for a Popular App engagement is a working integration, not a feasibility memo. Concretely, what you get:

• Runnable source for the core surfaces — balance and movements read across DOP, USD and EUR; card and loan ledger reads; transfer history; the Popular Token session handler — in Python or Node.js to your preference.
• An OpenAPI specification describing the normalized output of each surface (so your downstream services do not need to know that “movimiento” means transaction).
• A short protocol and auth-flow report: how the session is established, where the Popular Token slots in, where the cookies live, and what error responses the bank returns under common failure modes.
• Automated tests against fixtures captured during the build, plus a smoke-test harness that can run against a live consenting account.
• Interface documentation written for the engineer who will maintain it after handover, not for a marketing reader.
• A short compliance note on data retention, consent records and how to revoke an account holder's authorization mid-flight.

A sketch of the call path

Illustrative shape, with field names confirmed during the build rather than guessed here:

# Movements read across a multi-currency Popular relationship
session = popular.login(
    user=os.environ["POPULAR_USER"],
    password=os.environ["POPULAR_PASS"],
    token=popular_token_now(),   # 6-digit OTP, regenerates ~60s
)

for cuenta in session.list_cuentas():
    # DOP / USD / EUR cuentas surface as separate objects
    movs = session.get(
        f"/cuentas/{cuenta.id}/movimientos",
        params={
            "desde": "2026-04-01",
            "hasta": "2026-04-30",
            "moneda": cuenta.moneda,   # "DOP" | "USD" | "EUR"
        },
    ).json()

    for m in movs["items"]:
        yield {
            "account_id":  cuenta.id,
            "currency":    cuenta.moneda,
            "date":        m["fecha"],
            "description": m["concepto"],
            "amount":      m["monto"],
            "balance":     m["saldo"],
            "reference":   m.get("referencia"),
        }

# When the OTP rotates mid-read, the session handler refreshes
# without dropping the cursor, so a long month does not split.

Where this sits in Dominican law

Two pieces of Dominican law actually shape this work, and one piece does not yet. The Monetary and Financial Law is what carries the banking-secrecy obligations a third party must honour when handling account-holder data. The country's personal data protection statute is what governs consent capture, retention windows and the holder's right to revoke. Together those are enough to run an account-holder-consented integration today and document it cleanly.

The open finance framework is the piece that does not yet apply as in-force regulation. The Superintendencia de Bancos has been working with Adofintech, the Hub de Innovacion Financiera and the IFC on it — the III Open Banking Forum and an IFC letter of commitment are the public touchpoints — but there is no AIS rule on the books to lean on the way you would in Brazil or the UK. The page is honest about that, the build is honest about it, and the dependable basis stated to the account holder is their own authorization, with the bank's terms as the second layer. When the SB rule lands, the integration migrates onto it.

Notes from the build — how we plan around the app

A few things shape an honest engagement on this specific app, and they are worth saying out loud because they affect schedule and design choices.

• The Popular Token refresh is roughly a minute. We design the session handler so a long movements read does not silently expire when the OTP rotates — the handler refreshes through the same generator the user enrolled, holding the cursor in place. Skipping that detail is the single most common cause of half-page reads in this market.
• DOP, USD and EUR are separate cuenta objects, not sub-balances of one account. We map them as distinct records under one holder. Flattening currencies after the fact loses the FX-rate context that reconciliation actually needs.
• Popular ships periodic redesigns. The bank has been visibly pushing digital and rolling new features into the app since its 60th-anniversary refresh. We schedule a follow-up alignment check after a bank-side release so a renamed field does not quietly break a parser.
• Retail and tPago live on shared infrastructure but are not the same surface. Where a client needs both, we split the build — same auth chain on the outside, different transaction models on the inside.

Where these notes come from

This was put together from the bank's own Play Store listing for the Popular App, Banco Popular Dominicano press notes on the Popular Token and digital services, World Finance reporting on the bank's digital push around its 60th anniversary, and the Superintendencia de Bancos communication on the open finance work it is running with Adofintech and the Hub de Innovacion Financiera. Mapping reviewed by the OpenBanking Studio integration desk, May 2026.

• Popular App on Google Play (com.popular.app.android)
• Popular en Linea press note on the Popular Token in the app
• World Finance on Popular's digital product suite
• Superintendencia de Bancos on the open finance work with Adofintech

Adjacent apps in the same market

If a client integrating the Popular App also wants to cover the rest of a customer's Dominican banking footprint, these are the apps that come up in the same conversation. Listed as ecosystem context, not as competitor scoring.

• Banreservas — the state-owned bank's app, similar shape behind the login (balances, transfers, cards) with a heavy remittance focus for the Dominican diaspora.
• BHD Leon — one of the largest private banks, account and card surfaces plus a digital wallet account, similar integration model.
• Scotiabank Republica Dominicana — the local arm of an international bank, retail account surfaces and bilingual UI.
• Banco Caribe — mid-size retail bank with branches and sub-agents, account and loan surfaces in the app.
• APAP — savings and loan association with fee-free savings accounts; the data shape behind the login is comparable to the bank apps.
• Qik Banco Digital Dominicano — digital-only Dominican bank, account and card surfaces, no branch leg.
• Comerza — Popular's commission-free digital account for micro-businesses; same infrastructure as the main Popular App, different segment.
• Yava — Popular's remittance-management app, useful when the integration target is incoming remittance flow.
• Gnial — Popular's youth-segment app, lighter surface set, same auth model.

Interface evidence

Public screenshots from the Popular App listing, kept for reference to the surface labels above.

Questions we get on this one

Does the Popular Token block automated reads of an account?

Not in the way most TOTP flows do. The Popular Token is a 6-digit code that the Popular App can auto-validate against the same session it generated it in, so an account-holder-consented build re-uses that generator rather than fighting it. We plan session lifetime around the roughly 60-second refresh so a long read does not get cut off mid-page.

Can DOP, USD and EUR accounts come out in one feed?

Yes. Popular treats peso, dollar and euro cuentas as separate account objects under one holder, so we keep them as separate records and let each transaction stay currency-tagged. Flattening currencies after the fact is where most third-party feeds in this market lose accuracy on reconciliation.

What is the regulator situation for third-party access to a Dominican bank right now?

The Superintendencia de Bancos, together with Adofintech and the Hub de Innovacion Financiera, is still drafting the open finance framework. There has been an Open Banking Forum series and a working agreement with the IFC, but no in-force AIS rule the way the UK or Brazil have one. So the dependable basis here is the account holder's own authorization plus the bank's own terms, and that is what the build runs against.

How does this hold up when the Popular App gets a redesign?

Popular has been pushing digital hard and ships visible reshapes roughly once a year. The build is structured so a redesign mostly touches the surface mapping, not the auth chain or the schema, and a maintenance pass realigns it. We schedule that follow-up check as part of the engagement rather than billing it as a separate project.

A Popular App build on our side takes one to two weeks end to end. The price on offer is a flat from US$300 for the runnable source — paid only after we hand it over and you have signed off — or a pay-per-call hosted endpoint where there is no fee up front and you pay only for the queries you actually make. Either path starts in the same place: send the app name and the data you need from it through /contact.html, and the credentials, the consenting test account and the documentation paperwork are arranged with you during onboarding rather than treated as a hurdle you have to clear on your own.