Working With Masav: What the Business Supplies, Who Issues What, How Long It Takes

Setting up against Masav is not one process but three, at three different parties: the bank issues an institution code, Masav opens the entity, and your system produces the file. Businesses nearly always stall at the handover between the first two, not at the third.

What Masav actually does

Masav - Automated Bank Services - is the clearing centre through which batched debit and credit instructions move between bank accounts in Israel. The two uses relevant to most businesses are recurring collection from customers under a direct debit mandate, and batched payment to a list of payees - suppliers or employees - in a single file.

What matters to understand before setup: Masav does not replace the bank and does not hold the money. It moves instructions between banks, so everything tied to the account, to the collecting entity's identity and to responsibility stays with the bank - and that is exactly what explains the order of the stages.

Stage one: an institution code from the bank

An institution code is the identifier of the collecting or paying entity in the system. It is issued by the bank where the account is held, on a request submitted at the branch, and only once it is in hand can the entity be opened at Masav.

What the bank is examining at this stage is who the business is and what it intends to collect. So it pays to arrive with an answer ready to three questions: what kind of collection, the estimated monthly charge volume, and who signs on behalf of the business. A request arriving without those comes back for completion, and that is the most common source of delay at this stage.

Stage two: opening the entity at Masav

After the institution code is issued, you complete a Masav opening form and submit it for processing. This stage also fixes the things that will affect every future run:

• Submission route - Masav's software, the bank's website, or an interface.
• Signing means - who signs and by what method.
• Activity type - debits, credits, or both.
• Operational contact - who receives notices about rejections.
• Credit account - where collected money lands.
• File structure - the format your system has to produce.

The item people overlook is the operational contact. Notices about rejected rows go there, and if that is somebody who has left or a mailbox nobody reads, rejections surface only when a customer calls to ask why they were not charged.

Stage three: the file itself

The third party is the system that produces the file in Masav's structure. There are two routes: an accounting or billing product that produces the file itself, or generating the file from an internal system according to the structure.

In both routes, what decides whether a run passes cleanly is data quality rather than format: a valid account number, an amount, and a reference identifying the customer. A row with a wrong check digit will be rejected regardless of how the file was built, and there is separate depth on that in bank account check digits and payment rejections and in errors in a supplier payment file.

What stalls businesses mid-way

The pattern repeats: the business builds the internal system first, because that is the part it controls, and then discovers the institution code has not been issued yet. The result is a ready system that cannot send anything, sometimes for weeks.

The reverse order works better: file the institution code request on day one, and only then start the implementation. The implementation stage can be compressed; the bank's response time cannot. Whoever runs this as a project with two parallel tracks finishes sooner than whoever runs it as a chain.

Two mistakes that recur at setup

The first is describing the activity too narrowly. A business that requests an institution code "for collecting from customers" and discovers six months later that it also wants to pay suppliers on the same route discovers, too, that this means going back to the bank rather than changing a setting itself. Stating both uses in the first request does not oblige you to use both.

The second is choosing the submission route to suit whoever does the setup rather than whoever will run it. If an outside consultant handles the implementation, it is convenient for them to pick the route they know; if in practice the bookkeeper runs it once a week, the route should be the one that suits her. It sounds marginal and it accumulates into tens of minutes a month, every month.

What to check before the first run

1. That the credit account in the file is genuinely the account the money should land in.
2. That there is a small test run - a handful of rows - before a full one.
3. That whoever receives the rejection report knows they receive it, and what to do with it.
4. That the submission date agreed matches the date the money is supposed to arrive.
5. That there is a written procedure for a rejected row, and a named owner for contacting the customer.

Those five checks look redundant before the first run and prove necessary at the second, when the run is ten times larger and nobody remembers what was agreed.

How long does it take end to end?

It depends on two things outside your control - the branch's response time on the institution code request, and the processing time on the opening form - so there is no single answer. What can be managed is not wasting that time: start the request immediately and, in parallel, prepare the data, the file structure and the rejection procedure, so that on the day the code arrives only a test run remains.

Sources

• Masav - customer charging service
• Masav - charges by authorisation
• Errors in a supplier payment file
• Direct debits against card charges
• Book a call