Page 18 - Methodology for inter-operator and cross-border P2P money transfers

Also, the question if MTCR shall be reported at all might be cases where either the network or the DFS
needs to be decided, w/r to non-representative infrastructure is temporarily down, i.e., a part of the
nature of testing. service is systematically unavailable. MTCR is there-
Remark 2: In cases where T6 is used as surrogate fore not only a technical element, but also a matter of
for T4 in case T4 is missing, MTACT is typically not testing perspective and scope of a testing campaign.
computed as there would be partial overlap with It needs to be clearly defined and documented how
MTCD and the sample basis is smaller in any case. these cases are treated, i.e., if and which transactions
If computation of MTACT shall be computed never- shall be removed from the valid set.
theless, it needs to be made clear in accompanying In the case of a campaign having explorative charac-
documentation (project report), that this is a second- ter, or seeking a broad perspective, a solution might
ary/auxiliary KPI. be to report different variants of MTCR to show the
Special consideration is required for the case of corridor of values, depending on respective deci-
MTCR, as the reported completion rate is depending sions.
on the number of unsuccessful transactions. There

10 CREATING THE USE CASE MODEL FROM ACTUAL USE CASE EXAMPLES

It has been shown that for creation of the basic • Have a high-quality audio comment providing
model of a DFS transaction, a well-produced video explanations of the steps to be taken, and com-
is best practice. ments on results where necessary. Ideally, these
A well-produced video is a persistent source of infor- comments already include references to actual
mation in detail and can be analysed easily. event-recording processes, e.g., mentioning the
In order to fulfil its purpose, videos should be “timer flags” to be recorded.
produced along the following guiding lines: • If feasible and for completeness, the screen of the
B party device should also visible. While this will
• Show the device screen in good, uniform lighting be of course impractical if the B party is in a differ-
and clarity, avoiding light reflections. ent location, it may be provided by another video
• Make sure that while there is of course the need showing the reaction of the device on an incoming
of manual operation, the screen is visible long DFS transaction.
enough in each step to allow following the flow of
events.

11 DATA SOURCES

In order to compute DFS KPI, respective input data na pilot test described in ITU-T Recommendation
need to be collected. P.1502.
Basically there are three sources of information:
Optionally, notification SMS on both sides of the DFS
• Recorded events from observation of the DFS use case. In the current context, these are not used
use case. In the context of the present document, as there is considerable effort to collect these data
these are events recorded by the Multi-stopwatch and their additional value is considered to be small.
(MSW) app. In case it is desired to use them, refer to the respec-
• Results from background measurement of the tive sections of ITU-T Recommendation P.1502, or the
transport network at each side of the DFS use respective FIGI reports (see References).
case. Basically this can be done by every suitable The data source apps are installed on platform devic-
QoS testing tool on the market. For the purpose es. On the Android operating system, running apps
of this document, it is assumed that background concurrently without cross-effects is not guaran-
testing is represented by the app named “DFS teed so the ideal configuration, from a fundamental-
Observer” which was also used in the first Gha- ist point of view, is to run each app on a separate
device. On the other hand, it is desirable to minimize

16 Methodology for inter-operator and cross-border P2P money transfers