Connecting to Lindo Remesa's Cuba transfer and rate records

Every quote Lindo Remesa shows — around 540 CUP to the dollar, roughly 1.15 USD to one MLC, a zero-fee promotion, as displayed on trylindo.com at the time of writing — is a server-side number. So is every transfer booked against that quote, every beneficiary saved for it, and every receipt the sender keeps. The app moves consumer money from the United States into Cuba and tracks each leg of that movement on its own backend. That backend is what an integrator wants to read.

The bottom line is short. Lindo holds an authenticated sender account, a recipient list keyed by payout method, a rate engine that re-prices regularly, and a transfer ledger that runs from quote to delivery confirmation. None of that leaves the device on its own, and the rate is not a static page — it is read live each time a sender opens a quote. The route we would take is to map the app's own client-to-server traffic under your authorization and rebuild it as a typed client, with a consenting account used to backfill historical transfers.

What Lindo holds on each transfer

These are the surfaces the app actually exposes to its own client, named the way a sender encounters them.

Routes to the transfer and rate records

Three routes apply to an app of this shape. Each is described by what it reaches, the effort, how durable it is, and what we set up to run it.

Authorized interface integration and protocol analysis

We observe the mobile client's own HTTPS traffic to the Lindo backend under your authorization, document the auth handshake, quote, beneficiary and transfer endpoints, and rebuild them as a typed client. Reaches the full live surface: quotes, recipient CRUD, transfer creation and status. Effort is moderate and front-loaded. Durability is good between app releases and we account for changes when one ships. Access is arranged with you during onboarding — capture runs against a consenting account or a test device we set up together.

User-consented account access

For history that pre-dates the integration, we operate against a Lindo account with the account holder's consent and walk the transfer ledger and receipts. Reaches everything the sender can see in the app. Effort is low once route one exists, since it reuses the same client. Durability tracks the app. We record the consent and keep the pull data-minimized to the records you actually need.

Native receipt export

Each transfer produces a Regulation E receipt the sender retains. Where that receipt is delivered or shareable, we normalize its fields as a fallback for environments where live calls are not wanted. Narrow but stable. Useful as a cross-check against the live ledger rather than a primary feed.

Of the three, protocol analysis is the one we would build the spine on, because it is the only route that gives live quotes and real-time transfer status rather than a snapshot. Consented account access sits alongside it to backfill the history the live surface does not return, and receipt normalization is kept as a reconciliation check. That is the shape we would propose for Lindo specifically.

The quote-to-payout call path

The flow a sender drives is small and predictable: authenticate, request a quote, attach a saved beneficiary, book the transfer, then poll it. The sketch below reflects that path; exact field names are confirmed during the build against the live client.

# Illustrative — field shapes confirmed during the protocol-analysis build

POST /v1/auth/login
  { "email": "...", "password": "..." }
  -> 200 { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }

# Live rate — never cached client-side, re-fetched per send
POST /v1/quote
  Authorization: Bearer <access_token>
  { "source_amount": 115.00, "source_currency": "USD", "payout": "MLC" }
  -> 200 {
       "quote_id": "qt_...", "rate": 1.15, "fee": 0.00,
       "dest_amount": 100.00, "dest_currency": "MLC",
       "expires_at": "2026-05-17T15:04:05Z" }

POST /v1/transfers
  { "quote_id": "qt_...", "beneficiary_id": "bn_...",
    "recipient_attestation": true }
  -> 201 { "transfer_id": "tr_...", "status": "created" }

GET /v1/transfers/tr_...
  -> 200 { "status": "in_transit", "payout": "MLC",
           "dest_amount": 100.00, "available_on": "2026-05-17",
           "receipt_url": "..." }

# Quote expiry guard the client must honor:
#   if now() > expires_at -> re-quote before POST /v1/transfers
# 401 on expired access_token -> POST /v1/auth/refresh, replay once

What you get back

The deliverable is a working integration, not a report. For Lindo that means:

• An OpenAPI specification covering auth, quote, beneficiary CRUD, transfer creation and status polling, with the quote-expiry contract written into it.
• A protocol and auth-flow report: the login-to-bearer chain, refresh handling, OTP if the build uses one, and the mobile transport notes (pinning, device checks) the client must satisfy.
• Runnable source for the key endpoints in Python and Node.js — a typed client that quotes, books, and tracks a transfer end to end.
• Automated tests, including the quote-expiry guard, the token-refresh replay, and CUP-versus-MLC beneficiary validation.
• Interface documentation a non-author engineer can follow.
• Compliance and data-retention guidance: which Reg E receipt fields to keep, how the recipient attestation flows through, and a GLBA-aligned data-minimization default.

OFAC, FinCEN and the Remittance Transfer Rule

Lindo's compliance posture is part of the data, so the integration has to respect it. The operator states it is registered with FinCEN as a money transmitter and licensed as a Florida Part II Money Services Business, and that transfers run under the Cuban Assets Control Regulations — 31 CFR 515.570 for authorized family and donative remittances, with the related 515.572 banking-institution services. Section 515.570 excludes recipients tied to the State Department's Cuba Restricted List, which is why the app collects a recipient attestation before a send.

On the consumer side, a US remittance provider falls under the CFPB Remittance Transfer Rule, the Regulation E amendment implementing Dodd-Frank section 1073, effective October 28, 2013 per the CFPB. That is why the quote and receipt objects carry an exact FX rate, fee, amount received, availability date and error-resolution text — structured fields, not free text, which is convenient for an integrator and obligatory for the operator. Our method is authorized, documented or user-consented access only: consent is logged, pulls are data-minimized, and an NDA is in place where the engagement needs one.

What we handle in the build

Concrete things about Lindo we plan for, so they do not surface as surprises:

• Quote volatility. The displayed rate updates regularly and each quote carries an expiry. We design the sync to re-quote and reconcile so a stale quote id never books a transfer at the wrong rate, and the zero-fee promotion is read as a server-driven flag rather than baked into the client.
• Payout-method branching. CUP, MLC and home-delivery recipients use different identifiers, and MLC cards differ across BPA, BANDEC and Banco Metropolitano. We scope the beneficiary schema per rail so the client validates the right field instead of failing at send time.
• Sanctions context carried through. The recipient attestation that 515.570 effectively requires is a field we preserve end to end; we do not re-make the authorization decision, we keep the one the app captured and log it.
• Mobile transport. The client may use certificate pinning or device attestation. Capture is arranged with you against a consenting account or test device during onboarding, and when Lindo publishes a new app release we re-confirm the endpoints against that build before handing changes back.

Where integrators take this

• A diaspora-services platform that lets a user send through Lindo from inside its own app, mirroring quote and status without rebuilding a remittance backend.
• A finance dashboard that reconciles a sender's outbound remittances against bank debits, pulling transfer amount, rate and availability date.
• A back-office tool that watches transfer status and fires a notification to the recipient's family when funds become available.
• A compliance archive that retains the Reg E receipt and recipient attestation per transfer, structured for audit rather than as loose PDFs.

A normalized transfer record

Across rails, we collapse the app's objects into one stable shape so a consumer does not branch on payout method:

{
  "transfer_id": "tr_...",
  "sender_ref": "acct_...",
  "beneficiary": {
    "rail": "MLC",                 // MLC | CUP | HOME_DELIVERY
    "identifier": "****-****-1234",
    "issuer": "BANDEC"             // null for non-card rails
  },
  "quote": { "source": "USD", "source_amount": 115.00,
             "rate": 1.15, "fee": 0.00,
             "dest": "MLC", "dest_amount": 100.00 },
  "status": "in_transit",          // created | funded | in_transit | delivered
  "available_on": "2026-05-17",
  "reg_e": { "receipt_url": "...", "attestation": true },
  "captured_at": "2026-05-17T15:10:00Z"
}

How this mapping was put together

Checked on 2026-05-17 against the operator's own site and store listings and against the primary regulatory texts. The app's payout rails, rate-match guarantee and stated licensing come from trylindo.com and the Google Play and App Store listings. The remittance authorization, the Cuba Restricted List exclusion and the disclosure obligations come from the CACR text and the CFPB and FinCEN sources cited here.

• trylindo.com — displayed rates, payout rails, money-back guarantee, stated licensing
• 31 CFR Part 515 (Cuban Assets Control Regulations) — section 515.570 authorized remittances
• CFPB — Electronic Fund Transfers (Regulation E) — Remittance Transfer Rule
• FinCEN — MSB registration — money-transmitter registration framework

Mapping and protocol notes by the OpenBanking Studio integration desk — reviewed May 2026.

Other Cuba remittance apps in the same picture

A unified remittance integration usually covers several of these. Each holds comparable records — senders, beneficiaries, quotes, transfer status — behind its own client, so one normalized schema can span them.

• Remitly — broad cross-border transfer service with sender accounts and tracked transfer status.
• Western Union — large network that resumed Cuba remittance service, holding payout and pickup records.
• MoneyGram — international transfer provider with sender profiles and delivery tracking.
• Sendvalu — Cuba-focused service for cash delivery and card top-ups, with per-transfer records.
• Fonmoney — MLC, card and cash-pickup transfers to Cuba with quote and status data.
• DUC App — CUP and USD delivery plus card top-ups, each as a tracked order.
• Ogvio — user-to-user transfers reaching Cuban recipients, with account ledgers.
• TropiPay — wallet and transfer service used for Cuba payouts and bank transfers.
• Remesita — USD and CUP remittances to Cuba with sender and recipient records.

Screens from the app

Store screenshots, for interface reference only.

Questions integrators ask about Lindo

Which records survive when the recipient is paid in CUP versus an MLC card?

Both follow the same transfer lifecycle, but the beneficiary object differs by payout method. A CUP payout carries a Cuban-peso card or home-delivery identifier; an MLC payout carries an MLC card tied to BPA, BANDEC or Banco Metropolitano. We model the beneficiary schema per payout method so the client validates the right identifier and the transfer record stays consistent across both.

Does the integration capture the Regulation E pre-payment disclosure and receipt fields?

Yes. A US money transmitter sending consumer remittances is subject to the CFPB Remittance Transfer Rule, the Regulation E amendment that implements Dodd-Frank section 1073 and took effect October 28, 2013. The pre-payment disclosure and receipt carry the FX rate, fees, amount the recipient receives, the date funds are available, and error-resolution rights. Those fields map directly onto the quote and transfer objects, and we preserve them in the normalized record.

How is OFAC's section 515.570 recipient screening reflected in what you pull?

Authorized family and donative remittances run under 31 CFR 515.570, which excludes recipients connected to the State Department's Cuba Restricted List. The app already collects a recipient attestation for this. We carry those attestation and screening fields through the integration rather than dropping them, and we do not re-make authorization determinations; we preserve the ones the app recorded and log the consent behind every pull.

If Lindo changes its displayed USD-to-CUP rate often, will a built client break?

No. The rate is never hardcoded; the client reads it from the live quote response at call time, along with the quote identifier and its expiry. Quote expiry is handled so a stale rate cannot book a transfer. When Lindo ships a new app release the request contract can shift, so we re-confirm the captured endpoints against the new build before handing any change back.

A typed Lindo client — quote, beneficiary, transfer, status — with its OpenAPI spec and tests lands inside one to two weeks. Source-code delivery starts at $300 and is billed only after the working build is in your hands and you are satisfied with it; if you would rather not host anything, call our endpoints instead and pay per call with nothing upfront. Give us the app name and what you need from its records and we take the rest from there — start at /contact.html.