Internet Banking Platforms

Why corporates still bank at a desk

The browser channel is often treated as the one mobile made redundant. For retail customers there is something in that. For corporate customers it is the other way round. A finance officer works at a desk, with a screen wide enough to read a payment run, a spreadsheet open beside it and a keyboard. Paying two hundred suppliers is not a larger version of sending money to a friend, it is a different task, and nobody does it on a phone.

What a company needs from its bank is volume, control and evidence. Volume, because salaries and supplier payments are prepared in one batch rather than one instruction at a time. Control, because the company's own rules about who may commit its money have to hold inside the bank's channel and not only in its internal policy. Evidence, because the finance team has to show an auditor who did what, and to get account activity into its accounting system without anyone retyping it.

Corporate relationships are among the most valuable a financial institution holds, and the channel is a large part of what keeps them. Balances sit where the payments are easy to make. An institution whose corporate customers still send instruction letters to a relationship manager is absorbing a cost and giving them a reason to listen to the next bank that calls. SACCOs and microfinance institutions meet the same pattern smaller: employers paying members, groups operating accounts jointly.

What a company's finance team can do on it

A corporate customer is not a user. It is a company, with a finance team, a mandate saying who may commit its money, and often several entities or projects under one relationship. If the channel cannot express that, the company works around it and the control moves quietly back into email.

The journeys we typically deliver start there. Several named users under one corporate customer, each with a role that decides what they may see and what they may do, from a clerk who prepares payments to a manager who approves them to an accountant who only reads. Payments released only once the people named in the company's mandate have approved them, in the number and combination the mandate requires. Bulk upload of salary and supplier runs prepared in the company's own payroll or accounting system. Transfers within the institution, to other banks and to mobile money. Standing instructions for regular commitments. Bill, statutory and tax payments. Statements and account activity for any period the company asks for, in a form its accountant can work with directly. And, against every instruction, a record of who prepared it, who approved it and when.

Then there is administration. When a finance officer leaves on a Friday, the company should be able to remove that person's access itself rather than write to a branch and wait. How much you delegate to the corporate and how much stays with your staff is your decision, and one of the more consequential in the build.

Which of these matters most differs by customer. A manufacturer with a weekly supplier run cares about batches and approvals; an NGO reporting to donors cares about statements. We scope against your actual corporate book, not a generic feature list.

The retail side of the same channel

Retail internet banking has a narrower job than it once had, and it is better built for that job than as the app reproduced in a browser. Most customers do most things on a phone. What they open a laptop for is the longer, more deliberate task: reading a full statement, producing one for a visa or a loan application, setting up a beneficiary carefully, working through a loan schedule.

There is also a group that prefers a desktop and will not change: older customers, professionals on a laptop all day, and the staff of your corporate customers. Customer information held here falls under Tanzania's Personal Data Protection Act, reason enough to be deliberate about what the channel shows and to whom.

The same bank in every channel

Internet banking should not behave like a separate institution. A limit, a fee, a cut-off time or a beneficiary should mean the same thing wherever a customer meets it. When they do not, customers experience the difference as being told different things depending on which channel they asked in, and the institution finds out through complaints.

What legitimately differs is scale and control. Mobile and USSD are built around one person acting alone on their own account. The browser channel carries the batch, the approval by several people, the reporting period and the delegated administration. The same products, at a different weight.

Channels bought separately, from different vendors at different times, drift apart. We build across mobile, USSD and payments too, so an internet banking engagement can extend what you run or start a wider programme.

What the institution has to settle first

Most of the effort in getting corporate internet banking live sits with the institution rather than with engineering, and much of it is settling things you now take case by case at a branch. The mandate comes first. Every corporate customer has an authorisation structure: who may commit funds, up to what value, and how many approvals are needed. On paper it lives in board resolutions and signature cards, and in practice your staff interpret it. In a channel it has to be expressed the same way for every corporate on the book, and turning the mandates you hold today into rules you can operate at scale is real work for your legal and operations teams.

Onboarding follows. Someone has to take a corporate from signature to first payment: documents collected, users named and verified, roles assigned, limits set, the customer trained. That is a branch and relationship management process, better designed while the channel is being built than in the weeks before launch. The same applies in reverse, when a company or one of its users leaves.

Two further decisions are yours. An entitlement policy, setting out what a corporate may do for itself and what it must ask you for. And the payment files your corporate customers will send, because their payroll and accounting systems produce what they produce. Agreeing what you will accept, with the customers who matter most, is worth starting early.

Finally, the service desk. Corporate users call, and they call about their own mandate, their own users and their own stuck payment far more often than about the institution. Staff who can see and explain a company's approval structure close those calls. Staff who cannot pass them to you. Training the desk belongs in the launch rather than after it.

How an engagement with us runs

We start with discovery: your corporate book, the mandates you actually operate, what your service desk spends its days on, and the systems the channel has to sit alongside. That produces a scope and a delivery plan, and the plan is yours whether or not we go on to build it.

Through delivery you see working software in an environment you control, so a real corporate customer can use it before go-live rather than at it. Source code and documentation are yours from the first commit. Afterwards we support the channel and train your people to take on as much of it as they want. There is no lock-in, by design and by contract.