Open Banking in Israel: What Business Account Data Can Actually Be Pulled

Open banking in Israel is a regulated infrastructure. Proper Conduct of Banking Business Directive 368 obliges banks, auxiliary corporations and acquirers to expose an account access interface, and the Financial Information Service Law defines who may consume it. A business reaches its own data through a licensed provider, not directly.

Two regulators, two different jobs

Israeli open banking is not administered by a single body, and conflating the two is the first mistake in any scoping conversation:

• The Supervisor of Banks at the Bank of Israel publishes Directive 368, "Implementation of an Open Banking Standard in Israel". It applies to a bank, an auxiliary corporation and an acquirer in their role as data source or payment account manager, and obliges them to open an account access interface.
• The Israel Securities Authority licenses and supervises the other end of the wire: financial information service providers, as defined in the Financial Information Service Law, 5782-2021.

The directive's technological standard is based on the European NextGenPSD2 framework, adapted to the Israeli financial system. The practical consequence for a developer: anyone who has seen a PSD2 implementation will recognise the shapes, but cannot lift an existing library and expect it to work unchanged.

Can a business connect straight to its own bank's interface?

Not in the form most businesses picture. The directive conditions interface access on three cumulative requirements: the caller identified itself at the transport layer with a suitable certificate, that certificate carries the role matching the requested service, and the certificate is valid. The certificate is a digitally signed credential issued by the relevant regulator through the government's digital services - not an API key you sign up for on a form.

Roles appear on the certificate as codes: PSP_AI for information consumption, PSP_PI for payment initiation, PSP_IC for a credit-granting body, and PSP_AS as a combined role. Transport itself is https over mTLS, and a payment account manager accepts only requests signed with an electronic seal certificate.

So the realistic route for a business is a contract with a provider that has already been through that process, not a development project against the bank. Data arriving that way is then handled like any other external feed, and the workflow around it is described in working with Bizibox between your accountant and the bank.

What the directive obliges a data source to provide

That last row is the gap that matters. Information access is read-only; writing a payment order is a separate service, with a separate certificate role, restricted to a one-off order in shekels.

Notice also what the table does not contain. No invoices, no supplier names, no accounting classification. The interface returns a bank transaction carrying whatever description the bank itself recorded, and everything that turns such a description into a bookkeeping line is built on your side. The directive also obliges every data source to publish a public developer portal and to offer certificate holders a sandbox - so documentation exists, but it is aimed at whoever already holds a certificate, not at a business's own development team.

What service level does the directive actually promise?

The directive states numbers, which is rare enough to plan around. Minimum monthly availability rises with the data source's seniority: 97 percent in its first year of operation, 98 in the second, 99 in the third, and 99.5 percent from the fourth year onward. Planned outages and known faults count as unavailability rather than being excluded from the calculation.

Alongside availability, two numbers bear directly on design:

• Freshness. Financial information or consent status must be supplied at the same currency as the data source's internet channels, with a lag of at most 30 seconds relative to them.
• History depth. For current account transactions and for debit card transactions and balances, the information must cover at least the 12 months preceding the request.

Those twelve months are what wrecks plans. A connection opened today does not manufacture your 2022 history, so an initial archive load is always a separate exercise from an ongoing feed.

Where the business case is weaker than the personal one

• Payment initiation. Under section 3.3.2, payment initiator access applies to an individual's payment account; in a joint payment account, one where all owners are individuals. That is not a footnote - it is why Israeli payment initiation services address consumers.
• Activity channel. The directive defines an activity channel as an internet channel of a data source separated from a similar channel for business reasons, giving business versus private channels as its example. The separation exists on the bank's side and shapes what reaches the other end.
• Signature structure. A business account has authorised signatories, powers of attorney and sometimes a two-signature requirement. Open banking consent was modelled around a customer, not around an organisational permission hierarchy.
• Non-bank sources. A large share of a business's financial picture sits with an acquirer, a payment service provider or a non-bank credit provider, and each of those is a separate route.

What to have ready before scoping

• The list of accounts and cards genuinely needed, by account number, rather than "everything we have".
• A decision on who inside the organisation grants access consent and who revokes it, including what happens when that person leaves.
• Somewhere to store a transaction under a stable identifier, so a repeated pull does not create duplicates - unpacked in the practical options for pulling bank and card transactions.
• A historical-load plan that does not depend on the interface, because the interface is only obliged to reach back 12 months.
• A defined behaviour for the interface being unavailable on month-end close, bearing in mind that even 99.5 percent availability is several hours a year.

Sources

• Proper Conduct of Banking Business Directive 368 - Implementation of an Open Banking Standard in Israel, Bank of Israel
• Financial Information Service Law, 5782-2021 - Israel Securities Authority
• Financial information service - Israel Securities Authority