Reaching the bank-by-bank rate feed behind Divisas - Tasas de Cambio

Five currencies, seven countries, and a separate buy-and-sell quote for every listed institution — that rate matrix is the asset behind Divisas - Tasas de Cambio. It lives on the app's backend and refreshes through the day. Per its Play Store listing the package is com.misdivisas.divisas, and the developer markets it for the Dominican Republic first, then Mexico, Colombia, Peru, Costa Rica, Guatemala and Nicaragua. A consumer opens it to compare the dollar at Banco Popular against Banco Reservas before a remittance or a business payment. A third party wants that same matrix as a clean feed.

The commercial spread — each bank's executable buy and sell — is what makes this app worth integrating, and it lives only on its backend, so the build centers on protocol analysis of the client-to-server traffic. We pull the official central-bank tables in parallel, less for the rates themselves than to anchor every commercial quote to a published reference and catch a bad capture. Reading a user's own favorites and alerts is a different, smaller job we take on only when someone needs a real account migrated.

Rate surfaces worth pulling

The screens map onto a small set of distinct data domains. Each is keyed by country, institution and currency, which is what makes the matrix joinable once it is normalized.

Three routes to the rate data

Client-to-server protocol analysis

Divisas's client talks to its backend over HTTP and JSON. We capture that traffic on a consenting device under your authorization, map the calls that return the rate matrix, the history series and the transfer-provider list, and rebuild them as documented endpoints. Effort is moderate: capture, decode, replay, then prove the shape against repeated pulls. Durability is medium because the app went through a full redesign recently, so the mapping needs periodic checking. This is the only route that yields the commercial buy/sell spread, which is the product.

Official reference feeds

The Dominican tax authority publishes daily exchange-rate tables, and the Banco Central reference rate is carried on the national open-data portal as a historical series; the other six markets have their own central-bank publications. Effort is low to moderate — parse published tables and files on a schedule. Durability is high, since these are government-published. This route gives the canonical reference rate, not the per-bank spread, so it complements rather than replaces the first.

User-consented preference data

Favorites and alert thresholds are tied to a particular install or account. With that user's express consent we can read their saved configuration only. Effort is low; the surface is narrow by design. Reach for this when a client wants to migrate a real user's alerts, not to obtain market data.

Mapping the rate-matrix call

The shape below is illustrative — exact paths, headers and token handling are confirmed during the build and not published here. It shows how we keep the official reference and the commercial spread as separate fields, and how every quote carries its own freshness stamp.

GET /v1/rates?country=DO&base=USD
Host: api.<divisas-backend>
Authorization: Bearer <app-issued token, rotated per install>
Accept: application/json

200 OK
{
  "country": "DO",
  "base": "USD",
  "as_of": "2026-06-15T13:40:05Z",
  "reference": { "source": "BCRD", "mid": 60.85 },   # official, kept separate
  "institutions": [
    { "id": "banco-popular", "name": "Banco Popular", "type": "bank",
      "buy": 59.90, "sell": 61.40, "updated": "2026-06-15T13:25:00Z" },
    { "id": "banreservas",   "name": "Banco Reservas", "type": "bank",
      "buy": 60.00, "sell": 61.25, "updated": "2026-06-15T13:10:00Z" }
  ]
}

# Error handling we wire in:
#   401            -> refresh the install token, retry once
#   stale 'updated'-> emit the quote with stale=true, do not drop it
#   missing market -> log and skip; never fabricate a mid

Numbers shown are placeholders, not quoted rates. The contract that matters is the field set: a per-country block, one reference mid, and an institution array where each entry is independently timestamped.

What you get at handoff

Everything is tied to the surfaces above, not a generic template.

• An OpenAPI specification for the normalized rate API we build over the mapped calls — country, reference, and per-institution buy/sell with timestamps.
• A protocol and auth-flow report covering the token chain as observed: how the install token is issued, carried and refreshed.
• Runnable source for the key endpoints in Python and Node.js — the rate-matrix pull, the history fetch, and an evaluator that reproduces the percentage-or-fixed alert logic.
• A small normalized schema so a Banco Popular quote in the DR feed and a Mexican bank quote key the same way. A trimmed example:

{
  "market": "DO",
  "currency": "USD",
  "institution_id": "banco-popular",
  "buy": 59.90, "sell": 61.40,
  "ref_mid": 60.85, "ref_source": "BCRD",
  "captured_at": "2026-06-15T13:25:00Z",
  "stale": false
}

• Automated tests: schema conformance, per-country coverage, and a freshness check that fails when a market's quote outruns its refresh window.
• Interface documentation and data-retention guidance written against Ley 172-13, covering what is stored, for how long, and what is dropped.

Freshness and staleness handling

Publication cadence is uneven across the region. Some markets put out a single daily reference; individual banks move intraday and the app reflects that. We stamp each quote with its own source time and compare it against that market's expected window, so a value that has aged out is flagged rather than served as current. For gaps — a market that goes quiet, a capture that drops — a small replay harness backfills from the last good pull and the official series, and marks the filled rows so downstream consumers can tell them apart.

Personal data, consent, and Ley 172-13

The bank and casa-de-cambio rates are public market data, so the rate feed itself carries no personal data and needs no consent. The personal surface is narrow: a user's favorites, their alert thresholds, and any device or push token. When a client needs that — the user-consented route — it falls under the Dominican data-protection law, Ley No. 172-13, promulgated in December 2013 per its published text, which requires express consent for processing and governs cross-border transfer of that data. Residents of the other markets fall under their own regimes, among them Mexico's LFPDPPP, Colombia's Ley 1581 de 2012, and Peru's Ley 29733. We work authorized and documented: access is logged, consent is recorded, data is minimized to what the feed actually uses, and an NDA covers the engagement where you need one.

What we plan around in this app

Two details from this specific app shape the build, and we handle both on our side.

First, the reference-versus-commercial distinction. The Banco Central reference rate is a weighted figure published for information; it is not what a consumer transacts at a branch, where the bank buys cheaper and sells dearer. We model the reference and each bank's executable spread as separate fields so the feed never passes one off as the other.

Second, the recent redesign. The developer shipped a full rework that added the transfer-provider comparison section, which means endpoint shapes can shift. We account for that churn by checking the mapped calls against a live capture on a schedule and patching the parser when a shape moves, so a front-end change is absorbed rather than allowed to break the feed.

A third, quieter one: institution names and types differ across the seven markets, so we key them to a stable registry. Access to a consenting device or account is arranged with you during onboarding; it is part of the work, not something you assemble first.

Screens we worked from

The published screenshots informed the surface map above. Open any to view it full size.

Comparable rate apps in the region

These sit in the same category and widen what a unified currency-data integration would touch. Listed for context, not ranked.

• Divisas LATAM — tracks bank and casa-de-cambio rates across several Latin American countries, overlapping closely on the rate-comparison use case.
• DolarHoy (El Dólar Hoy) — a web and app tracker covering the dollar against around twenty Latin American currencies, refreshed at short intervals.
• DolarApp (now ARQ) — a fintech for holding and moving digital dollars in parts of the region, so its data is account balances rather than market rates.
• DolarToday — a long-running Venezuela-focused rate reference whose figures are widely re-syndicated.
• Wise — a multi-currency account and transfer service that surfaces mid-market rates and per-transfer pricing.
• XE Currency — a converter and transfer app with broad currency coverage and historical charts.
• ALL Currency Converter — a converter spanning 171 currencies with rate alerts and multi-currency comparison.
• My Currency Converter & Rates — a lightweight converter covering more than 150 currencies, including the Colombian peso.
• Quezada Agente de Cambios — a Dominican exchange house that publishes its own buy and sell rates.

Questions integrators ask about this feed

Does the feed carry each bank's buy and sell spread, or only a single reference rate?

Both, kept as separate fields. The per-institution buy and sell come from the app's comparison screen — the commercial spread a consumer would actually transact at — while the central-bank reference rate, such as the BCRD figure for the Dominican Republic, sits alongside it as a distinct value so the two are never conflated.

Can you cover all seven markets at once, or one at a time?

Coverage is keyed per country, so the Dominican Republic, Mexico, Colombia, Peru, Costa Rica, Guatemala and Nicaragua can run together or in any subset you need. The commercial rates come from the app's backend; the canonical reference rate for each market comes from that country's official publisher.

How do you stop quotes going stale when markets update on different schedules?

Every quote is stamped with its own source timestamp, and the feed flags a value as stale once it passes that market's expected refresh window. Some markets publish a single daily reference while individual banks move intraday, so a global freshness rule would mislabel half of them.

The app was recently redesigned — will an integration built now keep working?

We expect front-end and endpoint changes and plan for them. The mapped calls are checked against a live capture on a schedule, and the parser is patched when a shape moves, so the redesign that added the transfer-provider comparison section is the kind of change the build absorbs rather than breaks on. Timing for the initial delivery is one to two weeks.

Sources checked

What we read, in June 2026: the app's Play Store listing for its feature set, currency and country coverage, and redesign notes; the Dominican tax authority's published exchange-rate tables; the Banco Central historical dollar series on the national open-data portal; and the text of Ley 172-13. Mapped by the OpenBanking Studio integration desk · June 2026.

• Divisas - Tasas de Cambio on Google Play
• DGII — published exchange-rate tables
• datos.gob.do — historical USD/DOP series
• Ley No. 172-13 on personal data protection

Working with us on this feed

You bring the app name and what you want from its data; we work out the route, arrange access with you, and deliver. Source-code delivery starts at $300 — you receive the runnable rate-API source, the OpenAPI spec, the tests and the documentation, and you pay after delivery once it satisfies you. The hosted option is pay-per-call: you call our endpoints and pay only for the calls, with no upfront fee. Either way the first delivery lands in one to two weeks. Tell us which markets and currencies you need on the contact page and we will scope it.