Binimoy Platform: Why Bangladesh MFS Interoperability Lags

That is the final scorecard of Binimoy, Bangladesh’s much-hyped Interoperable Digital Transaction Platform, which was suspended on August 3, 2025 after less than three years of operation.

Bangladesh Bank cited irregularities, contract violations, unpaid operational fees stretching back seven to eight months, and political pressure linked to the previous regime. Those are serious administrative failures. But the deeper problem was visible long before the shutdown: Binimoy was built as if connecting institutions were enough to create a useful payment network.

It was not.

For a country where bKash and Nagad have helped turn mobile financial services into everyday banking infrastructure, interoperability is not a decorative feature. It determines whether a merchant can accept money from any customer, whether a worker can send funds without maintaining several wallets, and whether digital payments can finally move beyond closed platforms.

Binimoy failed to solve that problem. The National Payment Switch Bangladesh, or NPSB, has since taken over the immediate interoperability role, with the framework allowing direct transfers between MFS providers from November 1, 2025. That means the old claim that Bangladesh’s payment rails simply do not connect is no longer accurate. They can connect through the NPSB framework.

The more difficult question is whether the connection is broad, reliable, affordable, and simple enough to change user behaviour.

The Rise and Fall of the IDTP: A Tk 65 Crore Misstep

Binimoy was designed as a common layer between banks, MFS providers, and payment service providers. In principle, that is exactly the kind of infrastructure Bangladesh needed. Customers were already spread across separate wallets and bank accounts. Merchants were already forced to manage several acceptance channels. A shared transaction platform could have reduced that fragmentation.

The problem was not the ambition. It was the product design and the institutional model surrounding it.

The platform required users to register a Virtual ID, or VID, for cross-platform transfers. In practice, both sides of a transaction needed to complete an additional registration step before the system could be used as intended. That introduced a new identity layer on top of accounts and wallets that users already understood.

This was a major mistake in a market where the success of MFS has been built on reducing the number of steps between opening an account and completing a transaction. A bKash user does not think of the underlying payment architecture each time money is sent. The service works because the product hides much of that complexity.

Binimoy exposed it.

In a country where digital literacy and connectivity vary sharply between central Dhaka and rural districts, every extra registration requirement has a cost. The cost is not only the time needed to complete the form. It is also the confusion created when a user has to understand why a separate identifier is necessary, whether the recipient has one, and which account is connected to it.

Binimoy did not merely add a technical step. It asked users to adopt a second identity system before they could experience the benefit of interoperability.

A network that never became a network

The institutional footprint was equally damaging. Binimoy connected eight banks, three MFS providers, and two PSPs. The participating banks included Sonali Bank, BRAC Bank, UCB Bank, Eastern Bank, Mutual Trust Bank, Pubali Bank, Al-Arafah Bank, and Midland Bank. The listed MFS participants were bKash, Rocket, and mCash.

That was not enough to create a dependable national network.

Payment systems become valuable when users can assume that the person or business on the other side is reachable. A platform with limited participation forces customers to ask the wrong question: not “How do I pay?” but “Which provider does the recipient use, and is that provider connected?”

The absence of major market participants was especially serious. Nagad and Upay were not part of the listed Binimoy network. That left a substantial portion of the MFS market outside the platform’s practical reach. Even where a theoretical route existed, the user experience was defined by exceptions.

The resulting product looked interoperable on paper while remaining fragmented in daily life.

The adoption problem was not only technical

Binimoy also suffered from weak user communication and poor market positioning. Users were expected to discover a new platform, understand its purpose, register a VID, and persuade others to do the same. That is a demanding adoption model even for a private app with a large marketing budget. For a government-backed infrastructure project, it was particularly unrealistic.

The Innovation Design and Entrepreneurship Academy, known as iDEA, under the ICT Division, was the documented developer associated with the platform. It is not accurate to describe the developer as the “iDEA Foundation.” That distinction matters because responsibility for a public technology project should not be blurred through loose naming. The ICT Division’s role as the sponsoring government structure and iDEA’s role as the academy responsible for development are not interchangeable.

The Tk 65 crore cost also became a symbol of the mismatch between public investment and practical output. Spending money on a switch does not create network effects by itself. The institutions must connect, the rules must be enforced, the interface must be usable, and customers must see an immediate reason to change their habits.

Binimoy struggled on each of those fronts.

Structural Flaws: Why Binimoy Failed to Gain Market Traction

The failure can be reduced to a handful of connected design decisions. None of them was fatal in isolation. Together, they made the platform difficult to use and difficult to scale.

1. It treated registration as a solution to a trust problem

A common identity can help a payment network route transactions. But an identity system is useful only when it simplifies the customer’s experience. Binimoy’s VID requirement did the opposite. It made the user responsible for understanding the system’s architecture.

A successful interoperability layer should be almost invisible. The customer chooses a recipient, confirms the amount, and receives a clear record of the transaction. The underlying switch, routing logic, settlement process, and compliance checks should remain in the background.

Binimoy made the identity layer part of the product.

That approach also created a two-sided adoption barrier. A sender could not gain much from registration if the recipient was not registered. A recipient had little incentive to register if few senders were using the service. This is the classic cold-start problem of payments, and it is why interoperability cannot be left to voluntary consumer discovery.

2. Participation was too narrow

There is a difference between integrating institutions and creating coverage. Eight banks may be enough for a pilot. Three MFS providers may be enough to test routing. They are not enough to support a national promise of “interoperable” payments.

The platform needed the largest providers because users follow liquidity and reach. If the services people use every day are missing, the network cannot generate the convenience required for adoption.

A payment switch also needs more than technical certification. It needs operational consistency:

• common transaction and dispute rules;
• predictable settlement between participants;
• clear responsibility when a transfer is delayed or reversed;
• customer support that can resolve cross-platform complaints;
• published service-performance data;
• and commercial terms that do not make interoperability unattractive to providers.

Binimoy’s institutional story suggested that the technical connection existed in limited form, but the wider operating model had not become mature enough to support mass use.

3. The business incentives were never fully aligned

MFS providers compete for customers, balances, merchant relationships, and transaction frequency. Interoperability can increase the usefulness of the overall ecosystem, but it can also reduce the advantage of keeping customers inside one provider’s network.

That conflict cannot be solved by asking companies to cooperate out of goodwill. It requires rules that make participation mandatory, fees that are commercially workable, and a governance structure that prevents the largest players from treating the shared network as optional.

Binimoy appears to have been caught between a public-service objective and a voluntary participation model. The state wanted universal connectivity, while providers still had reasons to protect their own closed-loop activity.

That is not a technical bug. It is a policy contradiction.

4. The interface was treated as secondary

Payment infrastructure is invisible when it works and painfully visible when it does not. A user does not care that a system uses a sophisticated switch if the registration flow is confusing, the recipient cannot be found, or the transaction status is unclear.

Reports from the period pointed to an unintuitive interface and limited promotional effort. Those weaknesses were not cosmetic. In digital payments, user experience is part of the infrastructure.

For cross-platform payments, the interface must answer basic questions instantly:

• Is the recipient eligible to receive the money?
• Which provider will receive it?
• What fee will the sender pay?
• Has the transaction been completed, held, or rejected?
• Who should be contacted if the money leaves the sender’s account but does not arrive?

If the answer to any of those questions is unclear, users return to cash or use a familiar workaround.

The Pivot to NPSB: Restoring Cross-Platform Transaction Stability

The immediate response to Binimoy’s failure was not to build another isolated switch. On November 1, 2025, Bangladesh Bank activated a broader interoperability framework through the National Payment Switch Bangladesh.

The NPSB had already been used for inter-bank transfers. Its expanded role brought direct transfers between MFS providers, banks, and PSPs into the same regulatory framework. This is an important correction to the earlier state of the market.

A bKash customer can now send money to a Nagad customer through the NPSB-based interoperability framework, provided the relevant services and channels are available for that transaction. The same principle applies across participating MFS, bank, and PSP routes. The practical challenge is no longer whether such a connection is permitted at all. It is whether every provider implements it consistently and whether the customer experience is clear enough to make it routine.

That distinction matters. Legal or regulatory interoperability is the foundation. It is not the finished building.

What the fee structure changes

The NPSB framework also introduced a clearer fee structure:

1. MFS-to-MFS, MFS-to-bank, or MFS-to-PSP transfers: up to Tk 8.50 per Tk 1,000, or 0.85%, paid by the sender.

2. Bank-to-MFS, bank-to-bank, or bank-to-PSP transfers: Tk 1.50 per Tk 1,000, or 0.15%.

3. PSP-originated transfers: Tk 2.00 per Tk 1,000, or 0.20%.

4. Receiver charges: no fee is imposed on the recipient across these transaction types.

For anyone comparing Binimoy transaction charges in Bangladesh with the current NPSB framework, this is the critical shift: the newer system establishes a route and a ceiling rather than leaving cross-platform pricing entirely uncertain.

The structure is not free. An MFS-originated transfer of Tk 1,000 can cost as much as Tk 8.50, which may be acceptable for a larger payment but significant for low-value transfers. A small merchant, domestic worker, or rural household may notice that charge immediately.

The asymmetry is also worth examining. MFS users face the highest proportional fee, while bank-originated transfers are cheaper. That may reflect cost assumptions, settlement arrangements, or a regulatory attempt to encourage bank-led digital payments. It may also reinforce the perception that interoperability is more affordable for formal banking customers than for the people who depend most heavily on mobile wallets.

The fee cap nevertheless removes one long-standing objection to cross-platform transfers. Providers can now see the commercial boundaries more clearly, while customers can make a more informed decision before confirming a transaction.

The NPSB framework fixes the legal connection first. Bangladesh’s next test is whether that connection feels dependable at the point of payment.

NPSB is a bridge, not the end state

The NPSB expansion is best understood as an operational bridge. It uses an existing national payment infrastructure rather than waiting for a completely new platform to be designed, tested, and adopted.

That has an obvious advantage: the country does not need to tolerate another long period in which interoperability exists mainly in policy announcements. It also carries a risk. An infrastructure built around inter-bank payments must now support the frequency and pattern of MFS activity, where transactions are often smaller, more numerous, and distributed across a much broader user base.

The question is not simply whether NPSB can route a transfer. It is whether the full service chain can remain stable during high demand, including authentication, fraud monitoring, settlement, notifications, dispute management, and reconciliation between providers.

A failed transfer is not a minor inconvenience when the sender is paying school fees, sending emergency money to a family member, or settling a small business invoice. Reliability has to be measured from the user’s perspective, not only from the switch’s technical logs.

Bangladesh Bank should therefore distinguish between:

• the number of institutions technically connected;
• the number of institutions actively processing interoperable transfers;
• the success rate of those transactions;
• the average time required for completion;
• the rate of reversals and disputes;
• and the actual value and volume of cross-platform payments.

Without that data, “interoperable” can become another headline rather than a measurable public service.

The Road to 2027: Building a Mojaloop-Based Future

The longer-term plan is the Interoperable Instant Payment System, or IIPS, based on the open-source Mojaloop platform. Bangladesh Bank announced the development in September 2025 and set a full rollout target for July 2027.

That is approximately 22 months from announcement to target, not roughly 18 months. The correction is more than a calendar detail. A 22-month implementation window is still aggressive for a nationwide payment system, but it describes the actual scale of the deadline more accurately.

Mojaloop was designed for interoperable real-time payments in markets where traditional banking access is uneven and mobile money plays a central role. Its open-source architecture can reduce dependence on a proprietary platform and may give Bangladesh more flexibility over integration, upgrades, and future expansion.

But open-source software does not remove the hardest parts of a public payment project. It does not decide who must join. It does not settle disputes between competing providers. It does not guarantee that a rural merchant’s failed transaction will be resolved quickly. And it does not make a confusing interface usable.

The IIPS project will be judged less by the choice of software than by the discipline of implementation.

Four decisions will determine whether IIPS succeeds

First, participation must be mandatory and enforceable.

Binimoy’s limited reach showed the weakness of voluntary integration. If major banks, MFS providers, or PSPs can delay participation without meaningful consequences, the new platform will reproduce the same network problem under a different name.

A mandate must include deadlines, technical standards, testing requirements, and penalties for non-compliance. It must also cover operational obligations after integration. Connecting once is not the same as maintaining a reliable service.

Second, governance must be separated from announcement culture.

A payment system requires an accountable operator with authority over standards, upgrades, service levels, and incident response. Bangladesh Bank can set the regulatory framework, but the day-to-day network needs a professional operational structure.

Users and providers should know who is responsible when:

• a transfer is debited but not credited;
• one participant’s system goes offline;
• a fraud alert blocks a legitimate payment;
• a customer disputes the fee;
• or a provider repeatedly misses service standards.

If accountability is divided among agencies and providers, the customer will be sent from one support channel to another. That is how trust disappears.

Third, user experience must be designed as a national standard.

IIPS should not force users to learn a new identity vocabulary before they can make a payment. The system should support familiar account and wallet journeys while handling the routing in the background.

A good interoperable transaction should make the provider boundaries almost irrelevant. The sender should not need to know which switch is being used. The recipient should not need a separate registration ritual simply because the money originated elsewhere. Fees and delivery status should be visible before confirmation.

This is where the bKash-Nagad transfer question becomes practical rather than theoretical. The existence of a route is valuable only if an ordinary user can find the recipient, understand the charge, complete the transfer, and receive proof that it worked.

Fourth, performance data must be public.

Bangladesh Bank should publish regular information on the NPSB framework and, later, IIPS. The data should include integration status, transaction volume, value, success rates, uptime, reversals, customer complaints, and average resolution times.

A public dashboard would also help separate policy success from promotional language. If cross-platform transfers are increasing, the market should be able to see it. If one provider is blocking or delaying integration, that should not remain hidden inside administrative correspondence.

New Fee Structures and the Path Toward a Cashless Economy

The government’s wider objective is not merely to give users another way to move money. It is to reduce dependence on cash across retail, remittances, commerce, and everyday household payments.

That objective depends on interoperability because Bangladesh’s digital economy is divided among platforms. Customers may have one wallet for a family transfer, another for a merchant payment, and a bank account for formal income. Businesses may accept several QR codes or account numbers because no single channel covers the entire customer base.

The current NPSB framework creates a path between those systems. It does not automatically erase the habits that grew around them.

Cash remains attractive because it is immediate, widely accepted, and free at the point of exchange. Digital payments must compete with that combination. A fee of 0.85% may be reasonable for a regulated, traceable transaction, but it can still discourage low-value payments. If merchants pass the cost to customers, the digital option becomes less attractive. If providers absorb the cost, they may have less incentive to promote the route.

The policy therefore needs to consider the economics of different use cases rather than treating every transfer as identical. A large bank-to-bank payment and a small MFS-to-MFS transfer do not have the same impact on a household budget or a merchant’s margin.

The fee structure should be evaluated against actual behaviour:

• Do customers use interoperability for new payments or merely for urgent exceptions?
• Are small merchants willing to accept cross-platform payments?
• Does the sender understand the fee before authorising the transfer?
• Are providers displaying the same information in comparable ways?
• Does the receiver get the money promptly enough to treat the service as cash-equivalent?
• Are disputes resolved without requiring the customer to understand which institution failed?

A cashless economy cannot be built by adding a switch to the back end while leaving the customer to navigate the front end alone.

What Bangladesh should avoid repeating

The lesson from Binimoy is not that Bangladesh should stop building public digital infrastructure. It is that infrastructure must be treated as a service, not as a launch event.

The next system needs:

• Universal coverage: all licensed MFS providers, banks, and PSPs should face the same integration expectations.
• Simple routing: users should be able to send money to a valid destination without learning the internal structure of the network.
• Visible pricing: the sender should see the exact fee before confirming, especially for small-value payments.
• Reliable settlement: a debit without a corresponding credit should trigger a clear, time-bound resolution process.
• Interoperable support: customers should not be forced to identify the technical source of a failure before receiving help.
• Open reporting: adoption and performance should be measured publicly rather than inferred from announcements.
• Room for innovation: common rails should allow providers to compete on products and service quality without rebuilding closed payment walls.

The Tk 65 crore spent on Binimoy is a sunk cost. Recovering that money is not possible. The useful return would be institutional learning: a clear understanding that payment networks fail when governance, incentives, and product design are treated as secondary to the platform itself.

The NPSB framework is already a meaningful change from the old fragmented position. Direct transfers between MFS providers are now allowed, including routes such as bKash to Nagad, rather than being impossible in principle. That corrects one of Binimoy’s most damaging limitations.

But permission is not adoption. A route that exists in a circular but fails in practice will not persuade customers to abandon cash. A route that works but is expensive will remain an emergency option. A route that is cheap but confusing will be ignored by everyone except specialists.

IIPS, with its Mojaloop-based architecture, offers a chance to build a more durable national layer. The target is July 2027, around 22 months after the September 2025 announcement. That is enough time to build and test a serious system if the project has clear ownership, enforced participation, and a disciplined rollout.

It is not enough time for another cycle of vague mandates, narrow integration, weak interfaces, and limited accountability.

Bangladesh does not lack payment users, mobile coverage, or demand for convenient digital transactions. It lacks a consistently enforced framework that makes the entire ecosystem behave like one network. Binimoy exposed that weakness. NPSB has begun to address it. The IIPS deadline will show whether the country has finally addressed the governance problem underneath.

The technology may determine how transactions move. The rules will determine whether they move at all.