Reading the prepaid-card ledger and transfer events behind Monox

Three backends sit behind one Monox login: a Bank of Jerusalem prepaid-card ledger, an 019 telecom account, and the cross-border transfer rails the app routes payments through. The integration problem is mostly one of streams. Card authorizations land continuously, transfer status moves through a handful of states, and the 019 line bills on its own clock. A clean pull treats each as its own source and lands them in one normalized shape downstream.

Monox is built for people who get paid onto a card rather than into a bank branch — its own site frames the prepaid Mastercard, issued through Bank of Jerusalem, as the way to receive a salary and send money home. So the data that matters to an integrator is transactional and time-ordered: what came in, what went out, where a transfer is in its lifecycle.

Where the data lives

Each row below maps a real surface in the app to where it originates, how fine-grained it is, and what an integrator typically does with it.

Routes that apply

A few genuinely fit this app. Each note covers what it reaches, how durable it is, and what we set up to run it.

Authorized interface integration

Protocol analysis of the app's own traffic, under the customer's authorization, reaches everything a Monox user sees: card ledger, transfer status, the 019 line, store orders. Effort is moderate and the durability tracks app releases, so we keep the capture and the schema versioned. Access is arranged with you during onboarding — the build runs against a consenting account, not a guess at the wire format.

Consented open-banking read

For the bank-ledger half — balances and transactions on the Bank of Jerusalem side — Israel's open-banking standard and the Financial Information Service Law give a standardized, consented feed. It ages well because it is a published interface, but it is narrower: the 019 telecom data and the remittance vendor statuses fall outside it.

Native export as a fallback

Where the app or website lets a user download their own statement, that export is a low-effort, durable supplement. It rarely carries the full field set, so we treat it as a backstop rather than the spine.

For full coverage we would build on the authorized-interface route and fold in the open-banking consented read for the bank ledger, where the standardized feed is the part most worth insulating from app changes. The export hangs off the side as a check.

A look at the pull

Sketch of the two halves we wire first — the cursor-paged card ledger and the transfer status stream. Field names here were drafted during the build and get confirmed against a live, consented session.

# Illustrative client for the Monox prepaid-card ledger and transfer events.
from monox_client import Session, EventLog

s = Session.from_consent(consent_ref)          # token minted under the user's authorization

# 1) Backfill the card ledger by cursor (Bank of Jerusalem prepaid Mastercard)
cursor = store.last_cursor("card_ledger")      # None on a first run
while True:
    page = s.card.transactions(card_id=CARD, after=cursor, limit=200)
    for tx in page.items:
        emit({
            "kind":          "card_txn",
            "id":            tx["id"],
            "posted_at":     tx["valueDate"],
            "amount_minor":  tx["amount"],        # ILS minor units
            "currency":      tx["currency"],
            "merchant":      tx.get("description"),  # original-encoding text
            "balance_after": tx["runningBalance"],
        })
    if not page.next:
        break
    cursor = page.next
    store.save_cursor("card_ledger", cursor)

# 2) Cross-border transfer status — read from a replayable log, not blind polling
for ev in EventLog(s, stream="transfers").read(from_offset=store.offset):
    record(ev)                                  # quoted -> funded -> paid_out
    store.offset = ev.offset                     # re-reading from an earlier offset replays cleanly

The session is minted from a consent reference, never from stored raw credentials. Errors fall into two cases: a transport failure retries against the same cursor, while a consent expiry surfaces as a distinct signal so the orchestration knows to re-authorize rather than loop.

What lands in your repo

The deliverable is code that runs against your own consented account, not a slide deck.

• Runnable source for the key surfaces — the card-ledger cursor client and the transfer-status consumer — in Python or Node.js, your pick.
• A queue or stream consumer with offset handling, so transfer events can be replayed and the card backfill resumes where it stopped.
• An automated test suite that asserts the normalized schema against recorded fixtures, so a field rename in the app shows up as a failed assertion.
• A normalized schema mapping every surface above into one record shape, with currency in minor units and original-encoding text preserved.
• An OpenAPI/Swagger description of the endpoints we use, plus an auth-flow and token-lifecycle write-up.
• Interface documentation and data-retention guidance covering consent records and logging.

Flows we'd wire first

• Salary reconciliation. An employer loads wages onto the prepaid card; you ingest the inbound card credits and match them against payroll.
• Remittance status board. Transfer events drive a back-office view that moves each send from quoted to funded to paid out.
• Spend export. Card transactions flow into an accounting ledger on a schedule, with FX and fees kept on each record.
• Unified statement. The 019 billing line and card spend combine into a single monthly view for the cardholder.

Consent and the rulebook

The bank-account side has a defined regime. The Bank of Israel runs an open-banking standard through Proper Conduct of Banking Business Directive no. 368, modeled on the NextGenPSD2 framework, with its first stage starting in 2021 (per the Bank of Israel). Account-aggregation and consented financial-information access then sit under the Financial Information Service Law, which the Israel Securities Authority supervises; the first provider licenses were granted in 2022 (per the Securities Authority and contemporaneous coverage). The Law Regulating Payment Services took effect in June 2024, moving parts of payment supervision to the Securities Authority.

On the privacy side, Israel's Protection of Privacy Law applies, recently strengthened by amendment, and Israel holds EU adequacy. Our default is consented or authorized access only: consent scope is recorded and time-bounded, access is logged, data is minimized to the fields a use case needs, and an NDA is in place where the engagement calls for one. The remittance and telecom surfaces, which fall outside the banking standard, run under the customer's own authorization rather than the open-banking consent path.

Things we plan around

Two technical realities shape the build, and we handle both rather than hand them to you.

• Two issuers, two clocks. The banking ledger (Bank of Jerusalem) and the telecom-and-store side (019) authenticate differently and refresh on different cadences. We model them as separate sources behind one schema, so a token lapse on one does not stall the other.
• Currency and corridor fidelity. Transfers cross currencies and route through more than one vendor. We normalize amounts to minor units and keep the original currency, vendor, and fee on every record, so FX and cost reconciliation stay exact instead of rounded.
• Hebrew and multi-language text. The app is multilingual and much of the source data is Hebrew. We keep merchant and description fields in their original encoding and add transliteration only as a separate field, where an integrator needs Latin-script search.

How the work is priced

Source code lands in your repository, and the invoice is settled only after it runs against a live Monox account and you are satisfied — that route starts at $300. The alternative is the hosted API: you call our endpoints for the card ledger, transfer status, and the rest, and pay per call with nothing upfront. Either way a first integration runs on a one-to-two-week cycle. Tell us the app and what you need from its data, and we arrange access and compliance with you from there — start at /contact.html.

Screens we worked from

Store screenshots of the app, used while sketching the surfaces above.

Same money-movement space

Other apps an integrator often meets alongside Monox, each holding adjacent per-user financial records that a unified integration would pull together. Listed for context, not ranked.

• Rewire (now Remitly) — a digital account for migrant workers in Israel, with salary load onto a card and low-cost cross-border transfers.
• myGMT (GMT Global Money Transfers) — a digital wallet with a prepaid card, transfers, and currency exchange aimed at foreign workers.
• Imagen — a prepaid Mastercard distributor for migrants in Israel, later acquired by Rewire.
• Xoom (PayPal) — sends money to bank deposit and cash pickup across Israel and back out.
• ACE Money Transfer — an app-based remittance service used by migrant workers to send money home.
• Western Union — global transfers backed by a wide cash-pickup network.
• Wise — multi-currency balances and mid-market FX transfers.
• WorldRemit — app-first international remittances to bank, cash, and wallet.

Questions integrators ask

Do you pull the card transactions as a batch or as a live stream?

Both, and they're modeled separately. The prepaid-card ledger is backfilled by cursor so a re-run picks up where it left off, while cross-border transfer status arrives as an event log the consumer reads from a stored offset. The build hands you both.

Can the regulated open-banking route alone cover everything Monox shows?

No. The Bank of Israel open-banking feed reaches the bank-account balance and transaction side, but the 019 telecom line, the store orders, and the remittance vendor statuses sit outside it. Full coverage uses the authorized-interface route, with the open-banking read layered in for the bank ledger.

Which regulator governs the bank-account data behind the prepaid card?

The banking ledger sits under the Bank of Israel's open-banking standard (Proper Conduct of Banking Business Directive no. 368) and the Financial Information Service Law, which the Israel Securities Authority supervises. We work through consented access under those frameworks.

How do you keep the Hebrew transaction descriptions usable downstream?

Merchant and description text comes through in its original encoding and stays intact in the normalized records. Where an integrator needs Latin-script search or matching, we add transliteration as a separate field rather than overwriting the source text.

Sources and review

Checked in June 2026 against the app's own landing page, its Google Play listing, and primary Israeli regulatory material. The Monox feature set and operator came from the Monox site; the prepaid-card history from public reporting on Bank of Jerusalem; the open-banking and financial-information framing from Bank of Israel publications.

• Monox landing page (features, operator, card brand)
• Monox on Google Play (com.telzar.monox)
• Bank of Israel — open-banking standard and Directive 368
• Bank of Jerusalem — prepaid card background

OpenFinance Lab · interface engineering notes — 2026-06-15.