API Integration and Open Banking Platforms

Why your pace is set by your core provider

The pattern is familiar to anyone who has tried to launch something new. The business has a product idea. The idea needs data or a transaction from the core banking system. That becomes a change request to the core provider, priced on their terms and scheduled against their roadmap. Then the same again for the next channel, the next partner, the next report.

The real cost of this is rarely a single invoice. It is the speed at which your institution can answer an opportunity. A fintech asks to work with you and the honest answer is a quote and a date from somebody else. A corporate customer asks for something a competitor already offers. Your board asks why a straightforward change takes two quarters. None of those are engineering conversations. They are all about who controls access to your own data.

It shapes the supplier relationship too. When one party is the only route into the information your institution runs on, that fact sits quietly behind the price of everything else they sell you.

What changes when the connections belong to you

An integration platform does not replace your core banking system and is not an attempt to. Your core keeps doing what it does. What changes is who owns the connections into it, and therefore who decides what gets built and when.

Commercially that shows up in three places. Cost, because a new channel or a new partner stops being a separate purchase from a supplier who has no competition. Time, because you can commit to a date in a partner conversation without asking a third party first. Position, because the connections and the channels built on them are your property, which changes the shape of a core renewal or a core replacement discussion.

The point is not that integration work disappears. It is that it becomes work you commission, own and can have reviewed, instead of a line item you accept.

The business this opens up

Most fintechs need a supervised institution behind them for accounts, settlement and the holding of customer funds. In practice they approach several and work with whoever can actually connect them. Every partner you take on brings balances, transaction volume and fee income. Every one you cannot serve in time goes to an institution that could.

Merchants, billers and aggregators want collections and payouts to reach their own systems without someone rekeying a report at the end of the day. Corporate customers want payroll, supplier payments and balance information to move between their own finance systems and their bank without a person in the middle. This is retention business more than acquisition business. A corporate customer whose systems are connected to you does not move for a small pricing difference.

What the capability is worth differs by institution. For a bank it is usually partners and corporate customers. For a telco it is offering wallet services to banks, merchants and billers on commercial terms. For SACCOs and microfinance institutions the value more often runs the other way: reaching payment providers, credit information and identity services, so members get services the institution never has to build itself. For a fintech it is consuming and providing at the same time, because that is the business.

Open banking is still a policy conversation across the region rather than a settled obligation here. Preparing for it is worth doing on commercial grounds alone. An institution that already controls its own connections would meet a sharing obligation as a policy and consent exercise. An institution that does not would meet it as a programme, priced by whoever holds the keys.

Where it sits under everything else

This is the one platform on this site your customers never see. Its users are your own channels, your partners, your corporate customers and your own staff. Mobile banking, internet banking, USSD, agency banking and payments all sit above it, and so does whatever you have not thought of yet.

That is why the order of purchase matters. Institutions usually buy channels one at a time, each scoped on its own, each with its access to the core arranged separately and often by a different supplier. The bill arrives later, as the cost and the delay attached to anything that touches more than one of them.

You do not have to do this first. It can be built alongside your first channel, or brought in once several already exist and the pattern has become expensive. We scope it against the systems you run and the commitments you have already made, not against an ideal estate.

What opening your services to others involves

Most of what determines whether this succeeds is not built by us. It is settled by you, and it is commercial, legal and operational rather than technical.

Start with your core provider agreement. What you are entitled to access, what you are permitted to expose to a third party, and what each of those costs, are contract questions. Some institutions find they have more room than they assumed. Others find the conversation needs reopening. Either way it is worth knowing before anything is designed, and it is frequently the longest lead time in the project.

Then the policy. Tanzania has a Personal Data Protection Act, and any arrangement in which customer information reaches a third party is a decision for your legal and compliance functions before it is a decision for anyone else. What may be shared, with whom, on whose instruction, and how a customer gives and withdraws consent, are yours to define. We build to the policy you set.

Then the terms for the parties who use your services. What a partner is charged, if anything. What each side carries when something goes wrong. How a partner is approved, and how one is removed. Who in your institution answers a partner's questions once they are live. All of that is easier to settle before the first partner than after the tenth.

Working with us

We start with discovery. That means working sessions with your business, technology and risk people to establish what you are contractually able to do, what you want to be able to offer, and which of those has a business case worth acting on. You get a scope and a plan you own, whether or not we go on to build it.

Through delivery you see working software in an environment you control, and your own engineers or an independent reviewer can read the code while the work is happening rather than at handover. The source code and the documentation are yours from the first commit. We support what we build, train your people to take on as much of it as they want, and we expect you to be able to leave. There is no lock-in, in the contract as well as in the code.