Payments & Lending
Digital Payments and Fund Transfer Platforms
Every channel you run is a way of giving one instruction: move money. We build the payments underneath, between accounts at your own institution, other banks, mobile money wallets and merchants, so the instruction completes wherever it is headed.
A market where money already moves everywhere
Tanzania's payments market is unusually connected. Money moves between mobile money wallets, between wallets and bank accounts, and between banks, and customers stopped treating any of that as remarkable some time ago. Someone paid into an account will move funds to a wallet the same day if a wallet is where they spend. A trader will take payment into whichever account the buyer finds easiest.
That sets the bar for what an account has to do. If moving money out to a wallet means a branch visit, arrives late, or costs enough that the customer notices, the account becomes the place a salary lands rather than the place money is used. The balance may stay with you. The transactions, and the fee income and customer insight that come with them, go to whoever made paying easy.
It runs the other way as well. An institution that can be paid into from any wallet and any bank is simply easier to do business with, whether the customer is a school collecting fees, a lender collecting repayments or a distributor collecting from traders. For institutions competing with wallet providers for the same people, payment reach is not a feature of the digital channel. It is the reason the customer keeps the account.
The payments you need to move
The commercial scope of a payments platform is best read as the list of payments your customers make and receive: transfers between a customer's own accounts and to other customers of your institution, transfers to and from other banks, transfers out to mobile money wallets and inbound funding from them, bill and utility payments, merchant payments including at the till, bulk disbursement for payroll, supplier runs, loan drawdowns and benefit programmes, standing instructions for payments that repeat, and inbound collections, where your customer is paid by people who bank somewhere else.
The mix matters more than the list. For a retail bank, outbound wallet transfers and bill payments carry most of the traffic. For a lender, inbound collections and repayments are the whole point. For an institution that banks employers, bulk disbursement is often what wins the mandate, and the payroll date is the day the service is judged on. Which payments you launch with is a commercial decision we take with you, based on where your volume and your fee income actually sit.
What customers notice is narrower than any of this. They want to know the money went, that they can see it went, and that the charge was the one they expected. Those are product decisions, and they take more discussion than the transaction list does.
Different institutions, different payment problems
A commercial bank needs breadth. Its customers expect to be able to pay anyone, and its corporate customers arrive with payroll, supplier payments and collections of their own. It also carries the heaviest expectations, being supervised by the Bank of Tanzania, and its risk and compliance functions will have firm views on limits, screening and approval that shape the product long before a customer sees it.
SACCOs and microfinance institutions have a narrower problem and a sharper one. Members are frequently paid through wallets and want to repay from them, and collecting a repayment without the member travelling to an office changes the economics of lending to them. The individual amounts are small, so the charging policy on each payment matters nearly as much as the payment itself.
Telcos and fintechs usually arrive from the other direction. They already hold the wallet or the merchant relationship, and what they need is the bank side of it, or a payments product they can sell on to businesses. Their pressure is time to market and the terms of the arrangements sitting behind them, rather than an existing book to protect.
Every other channel is a front door onto this
A mobile app, internet banking, a USSD menu, an agent, a teller and a corporate portal are all ways of giving the same instruction. Customers do not experience them as separate products. They experience having paid an electricity bill, or not having paid it.
Where those channels were bought separately over the years, customers feel the seams. Charges differ depending on which route they happened to take. A payment that worked in the app yesterday is not offered at the agent today, and nobody in the branch can say why. Finance and operations meet the same thing from the other side, in reporting that has to be assembled from several places before anyone can answer a simple question about volumes.
We build payments and the channels that reach them, so this can be scoped as the groundwork under channels you already run, or as a single programme covering both. Either way the scope is set against what you already have rather than against a standard product.
What launching payments actually involves
Reaching each destination is a commercial and regulatory arrangement before it is a build. Interbank reach depends on the schemes and switching arrangements you take part in and the membership terms attached to them. Wallet reach depends on an agreement with each mobile money operator, either directly or through an intermediary, with the usual trade-off between control and speed to launch. Accepting merchant payments needs acquiring arrangements. Each has its own approvals, its own commercial terms and its own lead time, and each belongs to you rather than to us.
Then there are decisions only you can make. The settlement account structure behind each arrangement, and who in finance owns the daily position on it. The charging policy: what each payment type costs, who bears it, and where you would rather compete on price than protect margin. Limits, by product and by customer segment, which your risk and compliance people own. And the operational process around exceptions: who a customer speaks to when a payment does not arrive, what they are told while it is being looked into, and how quickly you have committed to come back to them.
Banking is supervised by the Bank of Tanzania, and customer data falls under Tanzania's Personal Data Protection Act. Where a payment product touches either, the approvals are yours to obtain, and we build to the requirements your risk and compliance teams set. The commercial arrangements behind each destination are usually the longest lead time in the whole project, so starting them while scope is still being agreed is the most useful thing you can do.
Working with us
We start with discovery: your products, your customers, the arrangements you already hold and the constraints you genuinely operate under, then an agreed view of which payments launch first and what follows them. That produces a scope and a plan, and the plan is yours whether or not we go on to build it.
During delivery you see working software in an environment you control, not progress reports about it, and the source code and documentation are yours from the first commit. After launch we support the platform and train your people to take on as much of it as they want. There is no lock-in, by design and in the contract.
Related platforms
- Banking PlatformsMobile Banking PlatformsThe app is the channel most of your customers will judge you on. We build it for the phone they already own and the connection they already have, and for the transactions they would otherwise queue in a branch for.Read more
- Platform & InfrastructureAPI Integration and Open Banking PlatformsYour core banking system holds the data your institution runs on. What it costs to use that data, and how long you wait for it, is set by your core provider. This platform puts those connections in your hands, so a new channel or a new partner becomes a decision you make rather than a change request you queue.Read more
- Banking PlatformsAgency Banking PlatformsAgency banking puts your institution in places a branch will never pay for, through people who already trade there. We build it around both sides of the counter: the customer who wants a service, and the agent who is running a small business on their own cash.Read more
Talk to us about this
Tell us where you are now and what is in the way. We will walk you through how we would architect it, what it depends on, and the order we would build it in.