Page 27 - Methodology for inter-operator and cross-border P2P money transfers
P. 27
hour/minute information, e.g., 1.2.2020 23:59 This protocol needs to cover the following situations
in End_Allocation to cover the whole day of (based on cyclical role-switching in the DFS use
1.2.2020), or use respective DATEADD functions case):
in BETWEEN statements.
• Column names should be chosen to not contain • Normal operation: Teams need to start the proce-
blank spaces or other non-alphanumerical charac- dure by agreeing which team is having the initial
ters. This may ease data processing e.g., in SQL A-Party role.
data bases. If desired, creation of “friendly text” • If a team is currently having the B-Party role, and
for output can be done in respective SQL state- T7 occurs; how long should they wait until con-
ments, e.g., replacing underscore (_) by blanks. tinuing in the A-party role? This issue becomes
important when it is possible that T7 comes earlier
than T4 or T6.
• If a team is in the B-Party role, it is possible the
12 SPECIAL PROCEDURES IN THE FIELD transaction was successful but no notification
SMS is received (i.e., no T7 can be set). How should
teams act if expected events are overdue?
12�1 Operational protocol if A and B party do not • How should teams communicate when they want
communicate directly to pause or end testing?
If teams are operating in different locations, a robust
protocol is required which tells teams how and when The following figures show graphical representations
to act. of the main cases and recommended parameters of
the communication protocol.
Figure 6 – Team interaction – normal case
Methodology for inter-operator and cross-border P2P money transfers 25