Page 15 - Methodology for measurement of Quality of Service (QoS) Key Performance Performance Indicators (KPIs) for Digital Financial Services

■ NOTE 2: Some service implementations may also of- Figures 4-1 and 4-2 illustrate the perspectives graphically.
fer a “tokenized” transfer which is in effect also a P2P Figure 4-1 shows a MoMo implementation where all
transfer. In this case, the transfer done by the A party information is collected locally in the A side DFS agent
would create a token which can be transferred to a (e.g. an app, or a function implemented in the SIM of
B party. This type of transfer is considered to be a the device) and is then transferred to the DFS. In this
special case and is not considered here. example, the DFS sends three data items in response:

4.1.2 Event and action flow • The primary confirmation is sent to the A side’s local
The core of a P2P MoMo transfer consists of instructing agent
the DFS to transfer money from the A party’s account • A secondary confirmation may be sent also to the A
to the B party’s account. party through another channel, such as SMS
In order to do so, the service requires information
items such as the respective account ID’s, information • A confirmation that money has been transferred is
text for the transaction and the amount to be trans- sent to the B side. As this is an unsolicited message
ferred. Also, the transfer will be authenticated by pro- (the B party is not actively participating in the trans-
viding a respective token such as a PIN. fer), a respective channel (such as SMS) is used.
There are many conceivable ways the user interface
may be designed. Most details are not relevant for mod- In Figure 4-2, a MoMo implementation is shown where
elling of a generic use case—such as the order in which the information required for a DFS transaction is col-
required information items are gathered. lected successively by prompts from the server (inter-
mediate variants are also possible, where some informa-
4.1.2.1 Involvement of the mobile network in the MoMo tion is requested as a group).
process The figures also show a common element that is im-
There is, however, an important exception which is high- portant for both modelling and methodology. There is
ly relevant. This is the degree to which the mobile net- an event “Show TA completion” on the A side. It rep-
work is involved in the MoMo process. There are two resents a message from the service indicating that the
general options: transaction has been completed. It is therefore called

a) All information is collected locally, and afterwards a the primary completion indicator. Completion is used
single data block is sent to trigger the actual money here as the most general case for a distinctive message
transfer. This will be referred to as type A. from the system which by itself only marks a defined
end of the transaction, which can be a successful oper-
b) The information is collected item-wise, with exchange ation or an unsuccessful one. If the transaction has been
of data over the network after each step. This will be performed successfully, this event is also called primary
referred to as type B. success indicator.
These options define the extremes of a network involve- In real MoMo implementations, there are additional
ment type scale where an actual implementation is de- messages generated by the MoMo implementations,
scribed by a value between those extremes (assigning which contain a summary of the transaction (including,
them, eventually, type identifiers for easier reference). for the A side, information about fees charged). These
For instance, the local (A-party side) application may messages are typically sent by store and forward ser-
collect type and recipient of a payment, then validate vice such as SMS.
the user exists; then it may request the amount to be From a functional point of view, they can be consid-
transferred to check if it is within the limits of the A ered as additional information which is, at least for the
party’s balance and contract, and finally request the re- B side, important from of the customer perspective but
maining elements, including the A party’s authorization, not critical or indicative for the DFS core transaction;
to validate the transfer. debiting and crediting money has taken place already.
Consequently, these events and information elements
■ NOTE: The differences belong, from a generic mod- are considered to be secondary indicators; they are not
elling perspective of a MoMo transaction, to the ‘ser- crucial for the following considerations of type-variant
vice set-up phase’. Collecting the information is pre- dependent dynamics.
requisite to conduct the transaction, but these steps In the context of the current methodology, it is as-
do not provide any customer value by themselves. sumed that the SMS containing summary information
The customer value materializes in the actual per- represent the final and correct information about the
formance of the money transfer which is the subse- A and B side account balance. Technically, it is possi-
quent step. ble that these SMS may contain erroneous content with
respect to actual book-keeping. It is, for state-of-the-
art systems, unlikely that such an essential element of a
DFS implementation is faulty.

Methodology for measurement of Quality of Service (QoS) Key Performance Indicators (KPIs) for Digital Financial Services • 13Methodology for measurement of Quality of Service (QoS) Key Performance Indicators (KPIs) for Digital Financial Services • 13