Inside BnB POS: reaching the agent remittance ledger

Behind the login: what an agent counter writes to the backend

Every send-and-pay action an agent runs through BnB POS lands in BnB Transfer Corp's backend as a structured remittance record. The app's own description is terse — it lets partners and agents send and pay remittance transactions for customers — but that one sentence sits on top of a working money-transfer ledger. An agent who pays out a MoneyGram, Ria or Western Union transfer, or who deposits to a TipMe mobile wallet, is reading and writing rows a third party would want to query, reconcile, or mirror into its own books.

The data worth integrating is per-agent and account-bound: the list of sent and paid transactions, the corridor and payout method on each one, the customer details captured for compliance, and the agent's running float and commission. That is what this brief maps. The route we would build is the partner-authorized one — drive the same portal an agent already signs into, read the same screens, and hand back a clean interface over them.

The authorized ways in, and the one I'd build first

Three routes genuinely apply to an agent portal like this. They differ in what they reach and how much they cost to keep running.

Portal-session integration under the agent's credentials

We sign in as the consenting partner does, observe the authentication chain the app uses against the BnB backend, and re-implement the calls behind the transaction, payout and float screens. Reachable: everything the agent themselves can see. Effort is moderate; durability depends on how often BnB reshapes the front end, which we account for in maintenance. This is the route I would build first — it reaches the same records an agent already works with, with no dependency on a feature BnB may or may not expose.

Documented protocol analysis of the app's traffic

For the mobile client specifically, we capture and document the request and response shapes between BnB POS and its backend so the interface can be driven headlessly. This overlaps with the first route but is the right lens when a partner wants the phone app's exact behavior reproduced, including token refresh and error handling.

Native statement export, where a partner's portal offers one

Some agent portals expose a downloadable transaction statement. Where a BnB partner account has that, it is the cheapest path for periodic reconciliation and we wire it as a fallback for bulk history — it does not give live float, so it complements rather than replaces the session route.

What you get at the end

The deliverable is a working integration over the surfaces above, not a report. For BnB POS that means:

• An OpenAPI/Swagger description of the agent-portal interface we model — create-transaction, pay-transaction, the agent statement, and the float read.
• A protocol and auth-flow report covering the login, token issuance and refresh, and any cookie or session chain the portal relies on, written against what we confirm during the build.
• Runnable source for the key endpoints in Python and Node.js — list and pull transactions, post a payout lookup, read float and commission.
• Automated tests against a partner sandbox or a consenting agent account, so a front-end change surfaces as a failing test rather than a silent gap.
• Interface documentation, plus data-retention and minimization guidance for the KYC fields that ride along with each transaction.

A worked example: a day's payouts and the running float

The shape below is illustrative — exact paths and field names are confirmed against the live portal during the build, not asserted here. It shows the pattern: authenticate as the agent, page the transaction list for a window, then read float so the two reconcile.

# Illustrative — endpoint shapes are confirmed during the build.
session = bnb_login(agent_id, secret)          # token from the portal auth chain
token   = session["access_token"]

# 1) paid transactions for one business day
resp = GET("/agent/transactions",
           params={"type": "PAID", "from": "2026-06-05", "to": "2026-06-05"},
           headers={"Authorization": f"Bearer {token}"})

for txn in resp["items"]:
    record = {
        "ref":      txn["reference"],
        "corridor": txn["destination_country"],   # e.g. GN / SL / LR
        "channel":  txn["payout_method"],          # cash pickup, TipMe wallet, bank
        "amount":   txn["amount"],
        "status":   txn["status"],                 # PAID / PENDING / REVERSED
    }
    upsert_ledger(record)

# 2) read float so settlement reconciles against the list above
bal = GET("/agent/float", headers={"Authorization": f"Bearer {token}"})
assert bal["currency"] in ("USD", "GNF", "SLE", "LRD")
log_read(bal)   # keep the raw response for dispute tracing

Token expiry is the part that bites in practice, so the generated client refreshes on a 401 and retries once before failing the call — handling we confirm against the portal's actual behavior rather than guessing it.

Authorization, FINTRAC, and keeping agent data minimal

The legal footing here is straightforward and it is not an open-banking mandate. BnB Transfer Corp registers as a money services business with FINTRAC in Canada — registration number M14761258, per the public MSB registry and OpenGov records — which sets the AML and record-keeping posture but does not create a consumer data-sharing right. The dependable basis for our work is the partner or agent authorizing access to their own BnB account, in writing, as part of the engagement.

Because each transaction carries customer KYC fields, we treat data minimization as a build constraint: pull only the fields an integration needs, keep the rest out of the partner's store, and align retention with PIPEDA and the partner's AML obligations. Access is logged, consent is recorded, and an NDA covers the work where a partner asks for one. The payout corridors land in Guinea, Sierra Leone and Liberia, each licensed by its own central bank — we keep the integration's scope inside what the consenting partner is themselves authorized to transact.

Engineering details we plan around

Two things about BnB POS shape how we build, and we handle both on our side.

• Float is live, not a snapshot. An agent's balance moves with every paid transaction, so we design the sync to read float per settlement event and reconcile it against the transaction list, rather than caching a figure that goes stale within minutes.
• Multi-currency corridors. A single agent may settle in USD on the funding side and pay out in GNF, SLE or LRD. We model amount and currency as a pair on every record and normalize on read, so corridor reporting does not silently mix units.
• Front-end churn. Agent portals get reskinned. We build a re-validation pass into maintenance so that when BnB changes a screen, the tests catch it and we adjust the client before a partner notices a gap.

Access to a sandbox or a consenting agent account is arranged with you during onboarding; the build runs against whichever of those fits the partner, and the credentials never leave the engagement.

Where integrators put this

• A partner accounting system that mirrors every paid transaction nightly and reconciles counter cash against the float read.
• A liquidity dashboard that watches agent float across locations and alerts before an agent runs dry mid-day.
• A compliance pipeline that lifts the KYC fields per transaction into an existing AML/sanctions screen, minimized and logged.

Sourcing and review

This mapping was put together from the app's store listings, BnB Transfer Corp's own site, and the public money-services record, then checked against the agent portal's sign-in surfaces in June 2026. Primary sources I opened:

• BnB POS on Google Play — app description and package identity.
• BnB Transfer Corp / Cauridor "About" — operator, corridors, licensing markets.
• FINTRAC MSB record M14761258 — Canadian money-services registration.
• BnB agent / partner portal — the authenticated surface this brief targets.

Mapped by the OpenBanking Studio integration desk, June 2026.

Screens from the agent app

Other apps in the same remittance corridor

Partners rarely run one rail. These are the names that show up alongside BnB in West African corridors, each holding its own slice of transfer data that a unified integration can normalize against the BnB ledger:

• Sendwave — app-first transfers to several African markets including Liberia, with a wallet and USDC option; holds sender accounts and transfer history.
• Ria Money Transfer — global remitter reaching Guinea and Sierra Leone; cash pickup, bank deposit and wallet payouts.
• WorldRemit — transfers to Guinea-Conakry, Liberia and Sierra Leone; per-user transfer and recipient records.
• Remitly — corridor-priced transfers with delivery tracking and stored beneficiaries.
• TapTap Send — low-fee app remittances into African corridors; transaction and recipient history.
• Small World — multi-corridor remitter with cash and wallet payout options.
• MoneyGram — a payout network BnB agents settle against; reference-based pickups.
• Orange Money — mobile-money rail in parts of West Africa, a wallet endpoint for inbound transfers.
• Thunes — cross-border payments network behind several of the above; settlement and payout metadata.

Questions integrators ask about BnB POS

Which BnB POS surface actually holds the payout and commission records?

The send-and-pay screens an agent uses are backed by per-agent transaction records in BnB Transfer Corp's backend — sent and paid remittances, the corridor and payout method, settlement state, and the agent's running float and commission. We map those screens to their underlying calls and model the records as they appear to the logged-in agent.

Is there an open-banking regime for these West African corridors we should ride instead?

Not a consumer open-banking scheme that fits a remittance agent portal. The corridors run to Guinea, Sierra Leone and Liberia, where each central bank licenses money transfer separately; in BnB's home market, Canada, consumer-driven banking is still being stood up. So the dependable basis is the partner or agent authorizing access to their own BnB account, not a third-party data-sharing mandate.

How do you keep up with agent float balances that move in real time?

Float and commission shift with every paid transaction, so we treat them as live state rather than a nightly snapshot. The integration reads the balance with each settlement event and reconciles against the transaction list, and we log the read so a disputed figure can be traced back to the exact response we saw.

Can you deliver only the send-and-pay endpoints rather than wiring the whole portal?

Yes. We scope to the surfaces you name — for many partners that is just create-transaction, pay-transaction and the agent statement — and ship runnable source plus an OpenAPI description for those, leaving the rest of the portal untouched.

Pricing is simple and you see the work before you commit. Source-code delivery starts at $300, billed only after the integration is delivered and you are satisfied with it; the hosted alternative bills per API call against our endpoints with nothing upfront. Either way the cycle runs one to two weeks. Tell us the app name and what you need from its data, and we handle access, authorization and the rest — start at /contact.html.