Bank-Account Check Digits in Israel: Why Payments Are Rejected and Where the Real Check Happens

An account-legality check is arithmetic over the bank-branch-account triple, and it catches keying mistakes only. It does not prove the account exists, that it is active, or that it belongs to your supplier. Masav publishes a separate legality formula per bank, so no single algorithm covers every Israeli account number.

What does the legality check actually prove?

The check takes three fields - bank code, branch code, account number - and runs the calculation the bank defined for its own numbering space. If the result does not reconcile, one of the three was mistyped. That is the entire scope. It tests the shape a bank chose for its numbers, not the account record behind them.

Three genuinely different questions collapse into one in most teams:

• Is the number well formed? That is the legality check. It runs locally, with no network call and no cost.
• Does the account exist and is it active? Only the bank knows, and only through a dedicated service.
• Does it belong to the party we think it does? That is a match between a customer identifier and the account holder, and it cannot be inferred from the digits.

Why is there no single formula for all Israeli banks?

Because each bank built its account-numbering space independently, long before central standardisation. The length of the account number, which components enter the calculation, and whether the branch code participates are all decided at bank level. Masav consolidates those rules and publishes them in its file-building material, alongside the Hebrew character tables and the hash calculation steps.

The practical consequence: a correct implementation is a lookup keyed by bank code, not a single function. If your code validates every bank the same way, it is almost certainly applying one bank's formula to all of them.

Three layers of rejection, and when you learn about each

The third row is the one that costs money. A payment rejected a week after submission is almost never an arithmetic failure. It is an account that was closed, restricted, or replaced by the supplier without anyone updating the vendor record.

What ADIV verifies that the number cannot

ADIV is Masav's digital bank verification service. You submit a file containing account details and a customer identifier, Masav routes each record to the relevant bank, and the bank answers whether the account exists, whether it is active, and whether the identifier matches the account holder. Results come back as a consolidated response file, processed in batches.

That is a workflow difference, not only a technical one. Legality checking is synchronous and instant; bank verification is a batch cycle you have to schedule around. Anyone trying to verify a new supplier in real time inside a web form will find the model does not fit.

Building a verification step that reduces rejections

1. Separate collecting bank details from paying. New details enter a pending-verification state rather than the next payment run.
2. Run the legality check keyed by bank code while the user types, and point the message at the field that failed.
3. Send every new supplier, and every change of bank details, for bank verification before the first payment.
4. Store per record when it was verified, against what, and what came back. Without that timestamp there is no way to tell whether a payment relies on stale data.
5. Read the returns file automatically and freeze the rejected supplier, instead of resubmitting the same record next month.

What actually goes wrong

• Leading zeros lost in a spreadsheet. An account number that passed through Excel drops its leading zero, and the calculation either fails or, worse, succeeds against a different account.
• One bank's formula applied to all. It looks like it works because most suppliers bank at the same two institutions.
• A merged branch. Banks consolidate branches, and the old branch code stops being valid even though the account number never changed.
• Bank details changed by email. This is the main fraud vector in supplier payments, and no arithmetic check touches it.
• One-time verification. A supplier verified in 2022 is not a verified supplier in 2026.
• A swallowed rejection. The returns file arrives, nobody reads it, and the same record is rejected again every month.

What happens when a supplier changes bank mid-cycle

This is the scenario that produces the most expensive rejections, because all three layers pass and the money simply comes back. The supplier opens a new account, sends the details, somebody updates the record, and the month's file was already built and submitted against the old ones.

Handling it is mostly a matter of sequencing rather than code:

• Set a freeze point: once the file is built and before it is submitted, a change of bank details goes into the following cycle, not the current one.
• Flag every supplier whose details changed in the last 30 days and route them to a manual check before submission.
• Confirm the change on a second channel, by calling a number already held on the supplier record - never a number that arrived in the email announcing the change.
• Keep the previous details instead of overwriting them. When the return arrives you will need to know exactly which account the payment went to.
• Run bank verification against the new account before the first payment to it, even for a long-standing supplier.

Three things remove most of the rework before any change enters the payment path:

• The current Masav specification for the file type you are building, including the per-bank account-legality tables.
• One source of truth for supplier bank details, with a change history and an approver on every change.
• A standing process that reads the returns file and feeds rejections back onto the supplier record.

This is a technical description of a validation mechanism, not financial or legal advice. Binding formulas and requirements come from Masav's official specification and from the bank.

Related: errors in a Masav supplier payment file, the returns file and updating customer debt, from supplier invoice approval to a Masav file.

Sources

• File specifications, account legality and tables - Masav
• ADIV - digital bank verification - Masav