bit, Bank Hapoalim's wallet: what it records per account and the authorized way in

Bank Hapoalim runs bit, and since the Bank of Israel's open-banking directive took effect in April 2021 the account behind every bit balance sits inside a regulated, consent-based data-sharing standard. That single fact decides most of how an integration is built. Israeli press and the bank put bit at over two million users and the large majority of person-to-person transfer value in the country; whatever the exact share, it means the records inside it — who paid whom, which group still owes its share, what was set aside in a pocket — are the working financial history of a lot of people and small businesses. This brief covers what bit holds per account, the authorized way to reach it, and what an integration build hands over.

Inside Bank Hapoalim's open-banking perimeter

Israel's framework rests on the 2017 Law for Increasing Competition and Reducing Centralization in the Banking Market, with the Bank of Israel's Banking Supervision Department issuing the implementation guidelines. The standard adopted is the Berlin Group's NextGenPSD2 specification, adapted for the Israeli market, and it rolls out in stages: current-account balances and transactions first, then card transactions and payment initiation, then credit, deposits, savings and securities. Access is consent-based and a third party operating the regulated path is licensed by the Bank of Israel. For an integration this matters in a specific way: the regulated feed reaches the Bank Hapoalim account and card movements behind bit, with strong customer authentication and an explicit consent that the customer can revoke. We treat consent scope and its refresh window as design inputs, not afterthoughts: the integration is built to renew within the consent term and to stop cleanly when consent ends, with consent records and access logs kept as a matter of routine. An earlier, time-limited Bank of Israel cap on business turnover through bank wallets has since lapsed; a build is scoped to consumer payments and account data, and we flag early if a use case touches merchant flows, which have a different regulatory history.

What bit records, per account

These are the surfaces a consenting account actually exposes, named the way bit names them. Granularity below is what an integrator can expect to read and act on.

Carrefour Club card status and reward balance appear for accounts that hold the card; whether that surface is in scope depends on what the consenting account can see, so we confirm it during the build rather than assume it.

Reaching that data

Three routes apply here and they are complementary, not alternatives.

Regulated open-banking consent

With the customer's consent, the Bank of Israel standard reaches the Bank Hapoalim account and card movements behind bit. This route is durable and standardized — it changes on a regulator's timetable, not an app release — but it sees the bank account, not bit's own constructs. Strong: balances and dated transactions a customer is entitled to share.

Consented interface integration of the bit app

Run against a consenting account, this reaches the bit-layer surfaces the regulated feed never sees: Pockets, payment requests, group collections, FX pre-orders, Arnona entries. It is the richer route for what makes bit bit. It needs maintenance when the app front end changes, which we plan for rather than discover.

In-app history as a cross-check

Where the account can export or list its own transaction history inside the app, that serves as a low-frequency reconciliation cross-check against the other two — useful for catching drift, not for live sync.

For most customers the working spine is consented interface integration of the app, because the Pockets, requests and group surfaces are usually the point; the regulated feed is layered under it where a customer wants durable, standardized balance and transaction data on the underlying account. We say which to lead with after we see the use case, and build the join between them either way.

What lands at handoff

The output is a working integration for the bit surfaces you need, not a report about them. Concretely:

• An OpenAPI specification covering the bit surfaces in scope — balance and Pockets, the activity feed, requests, group collections — with the shekel/Hebrew field shapes documented.
• A protocol and auth-flow report: the device-bound session, token rotation, and step-up (OTP) handling as they behave for this app.
• Runnable source for the key calls in Python or Node.js — session bootstrap, paged activity pull, request and group reads — with the regulated account/card feed wired in where it is part of the design.
• Automated tests, including the consent-expiry and step-up paths so a renewal failure is caught loudly.
• Interface documentation, plus consent and data-retention guidance written against the Bank of Israel standard.

A worked call against bit

Illustrative shapes — exact field names and the auth sequence are confirmed against the live app during the build, and the regulated route uses the Berlin Group request shapes instead of the below.

POST /bit/session/refresh          # device-bound; the device is registered
  refresh_token = <rotated each call>
  device_id     = <bound during the consent step>
-> 200 { access_token, expires_in: 600 }

GET /bit/activity?from=2026-04-01&to=2026-04-30&cursor=<page>
  Authorization: Bearer <access_token>
  Accept-Language: he-IL           # responses return RTL / Hebrew labels
-> 200 {
     "items": [
       { "id":"...", "type":"p2p_out", "amount": -120.00,
         "currency":"ILS", "counterparty":"מ. כהן",
         "ts":"2026-04-12T08:21:33+03:00", "status":"settled" },
       { "id":"...", "type":"request_in", "amount": 60.00,
         "currency":"ILS", "status":"pending" }
     ],
     "next_cursor":"..." }

# 401 consent_expired   -> re-run the consent step; do not blind-retry
# 428 step_up_required  -> surface the OTP challenge to the consenting user
      

The normalization layer we ship turns counterparty, currency and ts into stable fields while keeping the original Hebrew string, so a downstream ledger gets both a clean record and the source text.

What we design around in bit

These are the things that decide whether the integration is correct, handled on our side as part of the build:

• bit's own constructs — Pockets, group collections, payment requests, FX pre-orders — are app-layer objects that the regulated account feed does not contain. We map them from the app interface and reconcile them against the account/card movements so the customer gets one coherent ledger instead of two partial views.
• Data returns Hebrew-labelled and right-to-left, amounts in shekels, timestamps in Israel time with daylight-saving shifts. We normalize currency, direction and timezone into a stable schema and keep the original Hebrew alongside, so downstream systems do not reorder or re-encode it.
• Sessions are device-bound and step-up protected the way bank wallets are. We design the sync around the consent-refresh and OTP windows so it renews cleanly, and when the bit front end shifts our own monitoring catches it and we update the mapping before it breaks for you.
• Access is arranged with you during onboarding; the build runs against a consenting account, with consent records and access logs kept and an NDA in place where the work needs one.

Where this gets used

• An Israeli bookkeeping tool pulling a sole trader's bit person-to-person income into their books, normalized to shekels with Hebrew counterparty names preserved.
• A club or class treasurer dashboard reading bit group collections to show, per member, who has paid and who has not.
• A personal-finance app showing bit balance and Pockets next to the underlying Bank Hapoalim account for one net position.

Screens we worked from

Store screenshots used while mapping the surfaces above. Select one to enlarge.

Other Israeli wallets in the same picture

Anyone aggregating Israeli payments meets these alongside bit. Listed for ecosystem context.

• PayBox — Israel Discount Bank's group-payments app; holds per-user transfer and shared-pot records.
• Pepper Pay — Bank Leumi / Pepper's cross-bank P2P service; holds contact-based transfer history.
• Max — Israeli card issuer app; holds card transaction and statement data.
• Isracard — Israeli card issuer app; holds card spend and billing records.
• Cal (ICC-Cal) — Israeli credit-card app; holds statements and instalment plans.
• Bank Leumi app — full bank app; holds current-account balances and transactions.
• Bank Hapoalim app — the parent bank app; holds the account that sits behind a bit balance.
• AnyPay — Israeli transfer app; holds peer payment records.

Questions integrators ask about bit

bit transfers clear in seconds. Does an integration see that same live state?

It sees both. Each item in the bit activity feed carries a status, so a pending payment request and a settled person-to-person transfer are distinguishable in the data we map. We hand back the status field unaltered and timestamp every poll, so a downstream ledger can hold a pending row and reconcile it once bit moves it to settled rather than guessing.

Does bit data come through Israel's open-banking APIs or through Bank Hapoalim and the app itself?

Both layers exist and a build usually uses each for what it is good at. The Bank of Israel open-banking standard exposes the underlying Bank Hapoalim account and card movements with the customer's consent. The constructs that only live in bit — Pockets, group collections, payment requests, foreign-currency pre-orders — are reached by consented interface integration of the bit app for that same account. We reconcile the two so the customer gets one ledger, not two partial ones.

Can the work cover Pockets, group collections and Arnona, or only the main balance?

All of them, as far as the consenting account can see them. Pockets are read as separate sub-balances, group collections as a group with per-member shares and paid or unpaid state, and Arnona and refund entries as line items in the activity feed with payee and reference. The scope is set by what that account is entitled to view, and we map exactly that.

The data comes back in Hebrew and right-to-left. How is that handled?

Counterparty names and labels return Hebrew and RTL, amounts in shekels, timestamps in Israel time with daylight-saving shifts. We normalize currency, direction and timezone into a stable schema and keep the original Hebrew strings alongside the normalized fields, so a downstream system can display either without mangling encoding or order.

What was checked, and when

Checked on 2026-05-17 against the bit Google Play listing for the current feature set, the Bank of Israel's open-banking guidelines for the regulatory frame and standard, the OpenBankingTracker country record for the law and timeline, and a Globes report for the history of the business-turnover restriction. Where a figure such as user count or per-month limits is cited, it is attributed to its source and not asserted as our own measurement.

• bit ביט — Google Play listing
• Bank of Israel — open-banking implementation guidelines
• OpenBankingTracker — Israel open banking
• Globes — Bank of Israel restricts bank payment apps

Mapped and written by the OpenBanking Studio integration desk, 17 May 2026.

A bit integration leaves the desk as runnable source for the calls you actually need, with the Hebrew/RTL normalization and consent handling already built in. Source-code delivery starts at $300, invoiced only after the code is in your hands and working against a consenting account; if you would rather not run the infrastructure, the same surfaces are available as a hosted, pay-per-call API with nothing paid up front. Either path runs a one-to-two-week cycle. Tell us it is bit and what you need from it, and we arrange access and the rest: start a bit integration.