Divisas - Tasas de Cambio: pulling bank-by-bank FX quotes out of seven LATAM markets

The interesting payload here is not one number, it is roughly forty: a buy and a sell side, per institution, per currency pair, across seven countries, refreshed on whatever cadence each source publishes. The app surfaces those as a single normalised list with alerts on top. An integration worth paying for has to keep that structure intact end-to-end and not flatten it to a single regional midpoint somewhere in the pipe.

Most of what a treasury or remittance team actually wants from this app is two things at once: a clean rate feed that mirrors what users see on screen, and a notifications channel that fires when a watched rate crosses a threshold. Our default route reconstructs the former through authorised protocol analysis of the app's own ingestion calls and re-points the build at the upstream regulators where the app draws from them directly. The latter we ship as a webhook receiver wired into the same store.

What you can actually pull out

Reaching the data

Three routes apply, in this order of priority:

Authorised interface integration on the app itself

Protocol analysis of the app's own traffic against an account you own, under a written authorisation we sign with you. We rebuild the rate-list and per-bank calls as a stable internal client, with a per-source adapter so the build does not depend on any one upstream staying still. For most consumers this is the route we lead with — same shape as the app, same coverage, no upstream guesswork.

Direct upstream feed integration where the source is public

Where the app aggregates from a regulator we already integrate, we re-point that branch upstream. The Banco Central de la República Dominicana publishes an open developer API at apibcrd.bancentral.gov.do; Banco de México exposes peso-dollar series SF43718 (determination date) and SF60653 (settlement) through its SIE API; the public TasaReal feed covers DR rates as JSON over REST. Going upstream where it is honest cuts a dependency on the app and is friendlier under data-protection law because nothing in the call refers to a user.

User-consented account access for the alert/favourite state

The per-user state (saved banks, alert rules) lives behind an account. Where a downstream product wants those carried over, we set the consent flow up with you, capture authorisation in a log we hand over with delivery, and limit the scope to exactly the alert and favourite endpoints — not the whole session.

What lands in your repo

Source first, paper after. We bias the delivery toward code you can run in a fresh checkout on day one:

• Python and Node.js clients for the rate-list, history, and alerts endpoints, with typed request/response models per country.
• Webhook receiver (Node.js or Python, your pick) for rate-alert delivery: parse, verify the signed payload, persist, ack.
• Per-source adapter layer behind a thin interface so BCRD, Banxico, TasaReal and per-bank scrapers are swappable without touching the consumer.
• Test harness with recorded fixtures per country, covering happy path, an empty rate list, a malformed institution row, and a missed publication window.
• Sync design doc covering polling cadence, backoff, deduplication of identical quotes, and how to replay a missed window without double-firing alerts.
• OpenAPI / Swagger spec for the surface we expose to your side, and a short auth-flow note covering token exchange and refresh.
• Compliance and retention note for the user-side state (alerts, favourites): consent log format, revocation handling, retention default.

Wire shape

Illustrative — the exact field names and signing scheme are confirmed during the build, not asserted here. The receiver side looks roughly like this:

POST /webhooks/divisas/rate-alert
Content-Type: application/json
X-OFL-Signature: t=1717420800,v1=<hmac-sha256>

{
  "rule_id":      "rl_8a4c…",
  "country":      "DO",
  "institution":  "banco-popular",
  "pair":         "USD/DOP",
  "side":         "sell",
  "trigger":      { "kind": "threshold", "at": 61.45 },
  "quote": {
    "buy":        61.20,
    "sell":       61.55,
    "as_of":      "2026-06-03T13:42:11-04:00",
    "source":     "app-mirror"
  },
  "trace_id":     "tr_2026-06-03…"
}

# Pulling the current per-country list looks like:
GET /v1/rates?country=DO&pair=USD/DOP
=> [{ "institution":"banco-reservas",
       "buy":61.10, "sell":61.65,
       "as_of":"2026-06-03T13:40:02-04:00" }, … ]

The rule_id and trace_id let the consumer drop duplicates if the upstream re-fires the same quote on a retry, and let support reconstruct what the user saw at the moment the alert went out. The Banxico-side calls reuse Banxico's SF43718 series id as the token key on our internal cache, so a Mexico-only consumer does not pay for the rest of the region.

Consent and the per-country regime

Most of what this app aggregates is publicly published reference data: central banks and commercial institutions disclose their daily and intraday quotes. That part of the integration carries no user data and no consent question — it is rate-publication telemetry. The user-side state is different: alerts and favourites belong to a specific account and are handled under whichever local regime applies.

The closest live open-finance touch-point for this corpus is Colombia. Per Latinia and the Superintendencia Financiera de Colombia, Colombia turned its open-finance scheme into a mandatory regime in April 2026, with banks operating on a twelve-month implementation runway. Where a downstream product wants to combine Divisas's quote stream with a Colombian account's own balance and transaction data, the SFC-supervised consent flow is the path. Brazil's Open Finance ecosystem (the most mature in the region, per Banco Central do Brasil's published consent and call-volume figures) is the equivalent on the Brazilian side, and we wire to it when a build extends beyond rates into customer-account data. Mexico's framework is still being rebuilt around the 2018 Fintech Law and is treated case-by-case.

Compliance posture is the same regardless of country: authorised access under written agreement, NDA where required, logged consent records for any user-side data, data minimisation against the named purpose, and a retention default that errs short. Nothing about that is a precondition we hand back to you — it is the way the build runs.

Things we plan around (so you do not have to)

Three things about this app that shape how we build it, written down so they are visible up front:

• Sources do not tick together. BCRD batches; Banxico publishes intraday; smaller commercial banks update on their own schedules, sometimes only on a request-driven cache. We model each source separately during onboarding and run the ingestion as a per-source poll with backoff, not a single global cycle. A slow source stays slow without dragging the rest down.
• Buy and sell are the signal — flatten at your peril. A naïve midpoint loses what users of this app actually trade against. The pipeline preserves both sides, the per-institution timestamp, and the source label, end-to-end. A downstream consumer that wants a midpoint can take one; we do not assume that for them.
• Alert rules need careful deduplication. Threshold and percentage rules over a noisy minute-by-minute quote stream will fire repeatedly unless the rule engine remembers the last-trigger state per (rule_id, side). We design that state in from the first commit, so a re-deployment does not produce a thundering herd of duplicate notifications on the upstream's first refresh.
• Country coverage will change. The publisher has expanded the country list before. Per-country adapters are isolated specifically so adding an eighth market is a localised piece of work, not a rewrite of the consumer.

How the work runs

The build runs in a one-to-two-week cycle and lands as runnable source. Source-code delivery starts at $300, paid only after the drop sits in your repository and you have signed off on it. The hosted alternative is a pay-per-call API on our infrastructure with no upfront commitment — you call our endpoints, we invoice for the calls you actually made. To start, the app name and a short note on which countries and currency pairs you need is enough; access, sandbox, and authorisation steps are part of the build, arranged with you during onboarding. Send the brief through here and we will come back with a route and a delivery date.

Sources checked

Checked in early June 2026: the app's own Google Play listing for coverage, currencies and feature surface; the Banco Central de la República Dominicana developer portal at apibcrd.bancentral.gov.do; the Banco de México SIE API entry at banxico.org.mx for the peso-dollar series identifiers; tasareal.com/en/docs as a comparison Dominican-rate API; and Latinia's tracking of Colombia's open-finance regime for the April 2026 mandatory-status note.

OpenFinance Lab · engineering notes, June 2026.

Adjacent apps in the same lane

Apps that overlap on the rate-aggregator or remit-with-rates angle, useful when a build needs to reconcile across more than one source:

• Xe Currency & Money Transfers — global mid-market quotes and rate alerts across 130 currencies; useful as a reference rate against the per-institution LATAM detail this app carries.
• Wise (Conversor de Moneda) — mid-market quotes plus an actual transfer rail; relevant when a build wants both a price and a way to act on it.
• OANDA Currency Converter — reference rates aggregated from market data contributors; used as a sanity-check feed.
• Remitly — corridor-specific send-money pricing into DR, MX, CO, PE, GT and others; complements Divisas's local-bank view with a remit-side price.
• My Currency Converter & Rates — 150+ currency converter on iOS; a thin alternative on the user-side conversion tool.
• ALL Currency Converter — 171-currency Android converter with rate alerts; equivalent on the alert dimension alone, without the bank-level granularity.
• TasaReal — DR-only public exchange-rate API with JSON over REST; sits one country deep where Divisas covers seven.
• Latinometrics — Latin American FX dashboard; helpful for cross-country normalisation when a build wants the regional context.
• Tipo de cambio de divisas (com.netzfrequenz.android.currencycalculator) — a separate LATAM-leaning rate calculator on Google Play; useful as a structural comparator for the per-country layout.

Questions integrators ask

Which countries and currency pairs does the feed actually carry, and at what granularity?

Per its Play Store listing, the app covers seven markets — Dominican Republic, Mexico, Colombia, Peru, Costa Rica, Guatemala, Nicaragua — and five quote currencies: USD, EUR, CHF, GBP, CAD. Each quote is split into a buy side and a sell side at the institution level, not collapsed to a midpoint. The integration preserves that split through to delivery, so a downstream consumer can see exactly what a customer saw on screen.

How fresh are the rates, and how does the sync cope with banks that batch their publication daily?

Freshness varies per source. BCRD batches its peso-dollar fixings on a daily cadence; Banxico's SIE publishes intraday windows; commercial banks within each country update on their own opaque schedules. We model each source separately during onboarding and run the ingestion as a per-source poll with backoff, not a global tick — so a slow source does not stall fresh quotes from a faster one in the same delivery.

Can the rate-alert webhook be pointed at our existing notification stack, or do you ship one?

Both options work. The default delivery is an HTTPS POST with the alert rule, the triggering quote and a per-rule trace id, to whichever endpoint you provide. If there is no internal endpoint to receive it, we ship a small Node.js or Python receiver as part of the source delivery.

What happens to the integration when a country's central bank changes its rate-publication endpoint?

Each per-country source sits behind a thin adapter layer so a change to BCRD or Banxico is one file, not a rewrite. The contract on the consumer side (the JSON shape and the webhook payload) does not move. The test harness includes recorded fixtures per source so a broken upstream shows up before delivery, not in production.