Pulling Jubielee transfers, wallet, and JubieCard activity into your stack

Every Jubielee transfer changes state more than once — initiated, screened, then paid out by wallet credit, cash pickup, or bank deposit — and each transition is a row a third-party ledger wants to capture. That, plus the wallet balance and the JubieCard activity behind each account, is the data this brief maps. The route we use does not depend on a published spec. We read the same backend the app's own mobile and web clients talk to, under the account holder's authorization, and turn it into code your services can run.

The bottom line: Jubielee holds a clean per-account money ledger and a card-spend stream, and both move enough to be worth treating as events rather than nightly snapshots. We would lead with the transfer ledger and wallet balance — the two surfaces almost every downstream use needs — and add JubieCard and JubieCash as their own event types feeding the same normalized records.

What Jubielee stores per account

These are the surfaces a consenting account exposes, named the way the app presents them.

Chat, photos, and voice notes also sit behind the account, but they rarely belong in a financial integration, so we leave them out unless a project specifically asks.

Reaching the wallet and transfer data

Two routes carry almost any Jubielee project; a third is a fallback.

Authorized interface analysis (the spine)

The mobile and web clients exchange JSON with a backend over an authenticated session. We capture that handshake under a consenting account, map the wallet, transfer, card, and bill-pay calls, and rebuild them as a typed client. Reach is broad — anything the app itself can show. Durability is good as long as we keep a recorded-fixture suite that flags payload changes. This is what we would recommend here, because the money ledger and card stream are exactly the surfaces these calls expose.

User-consented account access

For aggregation and personal-finance use, the integration runs as the account holder, with their explicit authorization, scoped to the surfaces they agree to share. Same underlying calls, tighter consent boundary, and a clean audit trail.

Native portal and receipts (fallback)

The web portal and the bill-pay site render statements and receipts that can be parsed where a real-time read is not needed. Slower and coarser, but a useful backfill source — Regulation E receipts already carry rate, fees, and availability in a predictable shape.

A transfer-status read, sketched

Endpoint shapes are mapped during the build against a consenting account, not lifted from any published document. The outline below shows the surface, not a contract.

# Illustrative — names confirmed during the build, not from a public spec.

POST  /m/auth/session         # device + credential -> bearer token
GET   /m/wallet/summary       # balances for each currency the account holds
GET   /m/transfers?cursor=…   # remittance ledger, newest first, paginated

# One transfer row, as the client renders it:
{
  "transfer_id": "TRF-…",
  "direction":   "send",                 # or "receive"
  "payout":      "cash_pickup",          # wallet | cash_pickup | bank_deposit
  "amount_src":  { "ccy": "USD", "minor": 20000 },
  "amount_dst":  { "ccy": "DOP", "minor": 1165000 },
  "fx_quote":    "…",                    # the rate shown for the Reg E receipt
  "status":      "funds_available",      # initiated -> in_review -> paid_out
  "updated_at":  "…Z"
}

Each change to status is one event. Because the ingest is a replayable log keyed by transfer and state, re-running it from any cursor rebuilds the same ledger rather than stacking duplicate rows — handy when a downstream service falls behind and needs to catch up.

What lands in your repo

The deliverable is working code first, with the written artifacts alongside it.

• Runnable clients in Python and Node.js for the wallet summary, transfer ledger, and JubieCard activity reads, plus a small CLI that pulls a backfill.
• An event-ingestion worker that turns transfer-status and card-authorization changes into messages on a queue or stream your services subscribe to, with a stored cursor for replay.
• Automated tests built on recorded response fixtures, covering the auth handshake, pagination, the two-currency amounts, and each status transition.
• A normalized schema that folds wallet, transfers, card, cash-out, and bill pay into one ledger model, so the three rails reconcile cleanly.
• An OpenAPI/Swagger description of the mapped surface, an auth-flow report covering the session and token-refresh chain, interface documentation, and notes on consent logging and data retention.

Where teams plug this in

• A money app showing a user's Jubielee wallet balance and recent sends next to their other accounts.
• A bookkeeping tool importing JubieCard spend for a small business that pays suppliers with the prepaid card.
• A back office matching JubieCash agent cash-outs to the wallet ledger for daily reconciliation.
• A consented aggregation service reading the transfer history to surface corridors, fees, and timing across providers.

Consent, the remittance rule, and AML posture

The dependable basis for access is the account holder's own authorization — that is what we build against and log. On the US side, the Remittance Transfer Rule under Regulation E (12 CFR Part 1005, subpart B), administered by the CFPB, is in force and shapes what a sender is shown: a pre-payment disclosure and a receipt carrying the exchange rate, fees, the amount the recipient gets, and the date funds are available. That is why the transfer payload is a tidy source for those exact fields.

As a money services business, the operator sits under FinCEN registration, Bank Secrecy Act obligations, and OFAC sanctions screening; those screens are what produce the compliance-hold states we model. On the Dominican side, the Superintendencia de Bancos oversees payment institutions, and DR data-protection rules expect safeguards on personal data leaving the country. We keep the integration consent-scoped and data-minimized, hold identity fields only where a use case needs them, and work under NDA where a project calls for it.

Things we handle on the build

A few specifics about Jubielee that we account for, so they do not surprise you later.

• Two amounts per transfer. A send carries a source figure and a destination figure in different currencies, plus the quote. We keep both legs in minor units and store the quote, since the destination amount is what the recipient and the receipt reflect.
• The full status lifecycle. A remittance can sit in compliance review before it pays out, or be returned. We model the held and returned states explicitly, so a "sent" transfer parked for screening reads as held, not lost.
• Three rails, one ledger. JubieCard authorizations, wallet sends, and JubieCash cash-out post differently. We map each as its own event type so they reconcile into a single normalized record.
• Two client surfaces. Some actions — bill pay especially — happen on the web portal as well as the phone. We reconcile both so a utility payment made on the web shows up in the same feed.

Access is arranged with you during onboarding; the build runs against a consenting account, credentials are handled under NDA and not retained past the engagement.

Working with us, and what it costs

A first runnable drop covers the wallet summary, the transfer ledger, and JubieCard reads — the surfaces most projects start from. Source-code delivery starts at $300: you receive the runnable client, the ingestion worker, tests, and docs, and you pay after delivery, once it is in your hands and working. If you would rather not host anything, the pay-per-call option lets you call our endpoints and pay only for the calls you make, with no upfront fee. Either way the first cycle runs one to two weeks. Tell us the app and what you want out of its data, and we will scope it — start a conversation here.

Screens we worked from

Public store screenshots of Jubielee App. Select to enlarge.

How this brief was put together

On 8 June 2026 we read Jubielee's Google Play listing, its published privacy policy, and corridor coverage from remittance-industry sources, and checked the live text of the US remittance rule that governs sender disclosures. Identifiers such as the package name and operator are stated as they appear on those listings, not independently verified. Sources opened:

• Jubielee App on Google Play
• Jubielee privacy policy
• 12 CFR Part 1005, subpart B — Remittance Transfers (eCFR)
• Inter-American Dialogue — remittance industry outlook, 2025

OpenFinance Lab — interface assessment, reviewed 2026-06-08.

Other apps in the same remittance corridor

Same-category services an integrator often unifies alongside Jubielee. Listed for context, not ranked.

• Remitly — remittances to many countries with bank deposit, cash pickup, and mobile-wallet payout; holds transfer history and saved recipients.
• Xoom (a PayPal service) — US, Canada, UK and EEA senders with bank deposit, cash pickup, wallet payout, and bill pay; transaction and recipient records behind an account.
• Western Union — cash and account-to-account transfers across most countries; sender profiles and transfer ledgers.
• MoneyGram — cash pickup and wallet payout across many corridors, with account-held transfer history.
• Félix Pago — WhatsApp-based remittances to Latin America; conversational transfer records and recipient data.
• Intermex — US-to-Latin-America transfers with agent payout; sender and transaction records.
• Sharemoney — Omnex Group's digital brand for US-to-Dominican-Republic and multi-corridor transfers; account transfer history.
• Wise — a multi-currency account holding many currencies at the mid-market rate; per-account balances and transfer records.
• Ria Money Transfer — a large agent network for cash and bank payout; transfer and recipient data per account.

Questions integrators ask about Jubielee

Can Jubielee's transfer feed be consumed as events, or only polled?

Both. The build models each remittance as a sequence of state changes — initiated, compliance review, paid out, returned — and the ingestion worker can push those transitions onto a queue or stream your services subscribe to, with a stored cursor so the log can be replayed from any point to rebuild ledger state.

How are the two currency amounts on a remittance represented?

A send carries a source amount and a destination amount in different currencies, plus the FX quote the app shows the sender. We normalize both legs to minor units and keep the quote, since the destination figure is what the recipient receives and what the receipt discloses.

Does the integration cover JubieCard and JubieCash, or only wallet transfers?

All three. JubieCard (the prepaid Visa) authorizations, wallet sends and receives, and JubieCash cash-out at participating agents post on different rails, so we map them as separate event types that feed one normalized ledger.

Which rules actually constrain a Jubielee data integration?

On the US side the Remittance Transfer Rule under Regulation E is in force and governs the disclosures a sender sees, which is why the transfer payload is a clean source for rate, fees and availability. Anti-money-laundering screening as a registered money services business is what produces the compliance-hold states. The dependable basis for access is the account holder's own authorization.

We have a consenting Jubielee account on the US-to-DR corridor — what happens after we reach out?

You tell us which surfaces you need — say wallet balance and the transfer ledger — and we arrange access with you, map the endpoints against that account, and hand back runnable code with tests. A first drop usually takes one to two weeks.