Switch: How Should Transactions be Routed?

This issue pre-supposes that the “scheme interoperability” option has been chosen. (See Issue: Interoperability)
Any multi-participant payments scheme requires a switching functionality to pass transactions from one participant to another. There are a variety of models in payments systems today that can be considered. A central “hub” switch is operated by the scheme manager, or a commercial operator is hired by the scheme manager. (Note that the central “hub” may actually be technically distributed, but is still under the logical control of a single entity.) In a non-hub model, each participant is free to pick a processor, or operator (who may need to be certified by the scheme), and these operators work to achieve technical interconnection among themselves.

Option “A”: Central Hub

A central hub is a simple and well understood structure. Moreover, having a central operational hub helps to strengthen the rule-making aspects of the scheme: a participant who is out of compliance with rules may be simply denied access to the hub. Many country payments schemes operate (directly or indirectly) central hubs at very low costs. A central hub may make regulation and supervision more efficient as well.
However, the central hub may, over time, prove more costly than a non-hub model, as the central hub is not competing for individual participant’s business. Its cost efficiency depends on aggressive management of the hub (again, either as an internal function or a processor-for-hire) by the scheme.

Option “B”: Non-Hub Model

In a distributed system, having operators or processors compete for participant business should keep costs low.
But the non-hub model may be more difficult to exert control by the scheme, as well as possibly weakening, the scheme’s ability to enforce rules. In addition, the operators or processors will need to technically interoperate with each other: there is a risk that this will add additional costs that will offset the advantages of the model.

The Financial Inclusion Perspective: Option “A” is slightly preferred

Given the objective of enabling multiple participants, to deliver low end-user pricing through competition, the Level One Project Guide prefers the central hub model, as being simpler to understand and to execute than a non-hub model. But either can work.