Reading an Osmo Money wallet across six markets and three custody partners

Where Osmo keeps the money, and how we reach it

Osmo provisions a US dollar account through Bridge Ventures LLC, holds Bitcoin custody through Osmo El Salvador S.A., and issues its card through Rain (Signify Holdings) for Visa and SOINSA for Mastercard — all named on its own site. One user's balance is therefore spread across several regulated partners before any of it reaches an outside system. That split is the first thing an integration has to respect.

What a user sees inside the app is a single hub: balances held as per-currency pockets (the site lists GTQ, USD, USDC, BTC and Costa Rican colones), a Visa or Mastercard, and a transfer screen that fans out to local rails in each market. The authorized way to reach that hub for a third party is user-consented interface integration — we work from a consenting account, map the app's session and traffic, and produce a clean client that returns the same records the owner can already see. Where the data sits in Brazil, the regulated Open Finance Brasil consent path is the better read, and we use it for that leg. The lead we would take is a batch-first one: pull the whole history once, then keep it current.

What Osmo actually holds

The authorized routes that fit this app

1. User-consented interface integration

This is the spine. Working from an account whose owner consents, we map the login and token chain, then the calls behind the pockets, card and transfer screens, and build a client that returns those records on demand. It reaches everything the user can see, across every market, in one place. Durability is good as long as we track app changes; access is arranged with the client during onboarding, against a consenting account, so nothing in this route waits on a vendor.

2. Open Finance Brasil consent for the PIX leg

Brazil runs a regulated data-sharing regime under Banco Central do Brasil, with consent handled as an OAuth 2.0 protected resource and data released only against an active, authorised consent. Where a user's Brazilian account and PIX history are in scope, this regulated read is more durable than scraping a screen. It is jurisdiction-bound — it covers the Brazil leg, not the Guatemala or El Salvador pockets — so it complements route 1 rather than replacing it.

3. In-app statements as a backfill source

Where Osmo lets a user pull a statement or activity file, that export is a clean way to seed history on the first run. It is slower and less structured than the live route, so we treat it as a backfill aid, not the ongoing feed.

For most teams the practical build is route 1 as the live feed, route 2 layered on for anyone with Brazilian data who wants the regulated path, and any in-app export used once to fill in the deep history.

A backfill pass against the wallet

The snippet below sketches the first run: refresh the session, page the full transfer and pocket history through a cursor, and normalize each rail into one shape. It is illustrative — exact field names and the auth handshake are confirmed during the build against a consenting account.

class OsmoClient:
    def __init__(self, session):
        self.session = session            # consented session, refreshed on 401

    def pockets(self):
        # balance hub: one entry per currency pocket
        r = self.session.get("/wallet/pockets")
        return [
            {"asset": p["currency"],       # GTQ | USD | USDC | BTC | CRC
             "custody": p["partner"],      # e.g. Bridge Ventures, Osmo El Salvador
             "balance": p["available"]}
            for p in r.json()["pockets"]
        ]

    def transfers(self, cursor=None):
        # paginated history; loop until cursor is empty (batch backfill)
        params = {"limit": 100, "cursor": cursor}
        r = self.session.get("/transfers", params=params)
        body = r.json()
        rows = [normalize(t) for t in body["items"]]
        return rows, body.get("next_cursor")

def normalize(t):
    # collapse every rail onto one transfer schema
    return {
        "id": t["id"],                    # idempotency key for re-runs
        "rail": t["rail"],                # ach | wire | clabe | sinpe | pix | lightning | polygon
        "direction": t["direction"],      # in | out
        "src_asset": t["source"]["currency"],
        "dst_asset": t["destination"]["currency"],
        "fx_rate": t.get("fx", {}).get("rate"),
        "fee": t.get("fee"),
        "status": t["status"],            # pending | settled | failed
        "hash": t.get("onchain", {}).get("tx_hash"),  # present for BTC / Polygon
    }

def backfill(client):
    out, cursor = [], None
    while True:
        rows, cursor = client.transfers(cursor)
        out.extend(rows)
        if not cursor:
            break
    return out

What a finished Osmo build contains

• Runnable source — a Python or Node.js client covering pockets, card activity, transfers and the crypto ledger, with the batch backfill and the delta sync both implemented and the multi-rail normalizer included.
• Sync engine — the backfill-then-delta machinery wired up, idempotent on the Osmo transfer id, so a re-run reconciles rather than duplicates.
• Automated tests — fixtures for each rail (ACH, CLABE, SINPE, PIX, Lightning, Polygon) and the custody-split cases, so a change to one rail's shape shows up as a failed assertion.
• OpenAPI / Swagger spec — the surfaces we mapped, written up as a spec your stack can generate clients from.
• Protocol and auth-flow report — the session, token and refresh chain as we found it, with the error and retry behaviour.
• Interface documentation and a data-retention note — what each field means, plus how the integration logs access and minimizes what it stores.

Authorization, leg by leg

The basis we rely on everywhere is the account holder's own authorization to read their own records — consent captured, logged, and revocable, with an NDA where a client needs one. On top of that, each leg sits under a different supervisor. Bitcoin custody runs through Osmo El Salvador S.A., which the company describes as regulated by El Salvador's financial authorities — the country has built out a digital-asset regime through its national digital-asset commission and financial superintendent over the past two years. The Brazilian leg uses the Banco Central do Brasil Open Finance regime, where a Central-Bank-authorized operator reads data only against an active consent. The US dollar accounts are provisioned through a US partner and carry the money-services posture that comes with that; on the consumer-data side, the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is not in force — enforcement is enjoined and the rule is back in agency reconsideration — so we treat it as where US data-sharing may go, not as the rule we build against today. We design every read to be data-minimized: only the fields the use case needs, only for as long as it needs them.

Things this wallet makes us account for

Two specifics shape any honest Osmo build, and we handle both as part of the work.

One transfer schema across very different rails. ACH and Wire, CLABE, SINPE and SINPE Movil, PIX, Lightning and Polygon each report status, timing and fees their own way — an instant PIX settlement and a multi-day wire are not the same event with a different label. We map all of them onto a single transfer record so a row means the same thing whatever rail produced it, and so a PIX payout funded from a USD pocket reads as one transfer with two clearly-typed legs.

Custody-split balances. Because dollars, Bitcoin and the card sit with different partners — Bridge Ventures LLC, Osmo El Salvador S.A., Rain and SOINSA per the site — we tag each pocket and transaction with its custody and issuing partner. That keeps a USD balance from blurring into a BTC one in reconciliation, and it makes the proof-of-funds and accounting outputs trustworthy.

We also encode the availability matrix the app itself enforces — US transfers exclude accounts registered in New York, and product availability varies by location — so the integration never attempts a rail that is not offered in a given market.

Where teams wire Osmo in

• A payroll or contractor platform matching incoming USD pay (from Deel, Stripe, Payoneer or Wise) against the user's Osmo receiving details and pocket balance.
• An accounting tool pulling card activity and FX conversions to produce true-cost expense reports across currencies.
• A remittance dashboard tracking transfer status across ACH, CLABE, SINPE and PIX in one timeline, with Lightning and on-chain movements folded into the same ledger.
• A treasury view that reads the multi-currency pockets and tags each balance by custody partner for reconciliation.

Interface evidence

Store screenshots of the surfaces referenced above. Select to enlarge.

Where Osmo sits among cross-border wallets

These apps hold comparable data and come up when a team needs one normalized view across several wallets. Named for context, not ranked.

• Remitly — remittance app with strong US-to-Latin-America coverage; holds transfer history, recipient details and delivery status.
• WorldRemit — online transfers to bank, cash and mobile-wallet endpoints across many corridors; per-transfer records and payout method.
• Intermex — US-to-Latin-America money transfer with a Mexico and Guatemala focus; sender, recipient and settlement data.
• Wise — multi-currency balances and local account details in major markets; holds conversions, balances and transfer history.
• Strike — Bitcoin Lightning payments and cross-border send into Latin America; holds payment and Lightning ledger data.
• Vita Wallet — stablecoin-powered transfers across LATAM; balances and international transfer records.
• El Dorado — peer-to-peer stablecoin marketplace and wallet in the region; holds trades and wallet movements.
• Belo — Argentine wallet for global income, stable currencies and crypto; balances and transfer history.
• Takenos — wallet for LATAM cross-border workers to receive earnings in cash or crypto; payout and balance data.

Questions an Osmo integrator asks

If one transfer crosses rails — a PIX payout in Brazil funded from a US dollar pocket — how does the integration represent it?

As a single transfer record with two legs: the source pocket and currency on one side, the destination rail (PIX) and settlement currency on the other, with the FX rate and any rail fee attached. During the build we map every rail Osmo uses — ACH, Wire, CLABE, SINPE and SINPE Movil, PIX, Lightning and Polygon — onto one transfer schema so the leg fields mean the same thing whatever the rail.

Can you backfill historical Osmo activity, or only capture transactions from the integration date forward?

Both. The first run is a paginated batch backfill that walks the full transfer and pocket history through a cursor; after that a delta sync picks up new activity. The backfill is keyed on the Osmo transfer id, so re-running it reconciles against what is already stored instead of writing duplicate rows.

How is the Bitcoin and Lightning side shown next to the fiat pockets?

Each pocket is tagged with its asset and its custody partner, so a BTC or USDC balance never blurs into a USD one. On-chain, Lightning and Polygon movements carry their network and, where present, the transaction hash, which lets the same ledger feed support fiat reconciliation and crypto accounting at once.

Whose rules govern reading a given user's Osmo data?

It depends on where that slice of data lives. The dependable basis everywhere is the account holder's own authorization. For the Brazilian PIX leg, a Central-Bank-authorized Open Finance Brasil consent is the regulated read; Osmo's Bitcoin custody sits under El Salvador's financial supervisor; the US dollar accounts are provisioned through a US partner, where we treat the CFPB Personal Financial Data Rights rule as a forward-looking item, not current law, since its enforcement is enjoined and the rule is back in reconsideration.

Getting an Osmo build started

You give us the app name and what you want out of its data; we arrange access and the compliance paperwork with you, then build, on a one-to-two-week cycle. The source-code option puts a runnable client plus docs in your hands, and you settle from $300 once it is delivered and you are satisfied. If you would rather not host anything yourself, call our endpoints instead and pay per call, with nothing upfront. Tell us which fits and what Osmo data you need — start a conversation here.

Sources, and who checked them

This was put together on 2026-06-15 from the app's own listings and primary regulatory material: the Google Play entry for the package, Osmo's own site for the custody and card-issuer detail, reporting on the IBEX Lightning integration, and the Banco Central do Brasil Open Finance pages for the PIX consent route. Osmo Money assessment compiled by OpenFinance Lab, 2026-06-15.

Google Play listing · osmomoney.com (custody and issuers) · IBEX / Lightning integration · Open Finance, Banco Central do Brasil